DEV Community: Dennis Vorobyov

Augmented Team Quality: The Attrition Problem

Dennis Vorobyov — Thu, 25 Jun 2026 01:26:54 +0000

Everest Group's 2024 Staff Augmentation report found that 48% of augmented teams experience "high attrition" — defined as annual engineer turnover exceeding 25%. For a 5-person augmented team, that means losing 1-2 engineers per year. Each departure triggers the same costs as internal turnover — knowledge loss, ramp-up time, team disruption — but the client has no control over the staffing decisions because the engineers are employed by the vendor.

I run a staff augmentation business. The 48% number is the industry average, not our number. Our average engagement is 3+ years with the same engineers. The difference is the model, not the market.

Why Augmented Teams Churn

Utilization-driven rotation

Large staffing firms optimize for utilization, not client satisfaction. When a higher-paying engagement opens, the vendor moves the engineer from your project to the new one and assigns a replacement. From the vendor's perspective, this is rational — the same engineer generates more revenue on the new project. From your perspective, you just lost 6 months of domain knowledge and got someone who needs 2-3 months to ramp up.

The contractual language usually permits this. "The vendor reserves the right to substitute equivalent resources with reasonable notice." "Reasonable notice" might be 2 weeks. "Equivalent resources" might mean "same title, different person." The equivalency is in resume keywords, not in production experience with your codebase.

Engineer dissatisfaction with body-shop model

Good engineers do not want to be rotated between projects every 6 months. They want to build something, see it grow, and take pride in the result. The body-shop model — where the engineer is a fungible resource assigned wherever revenue is highest — treats engineers as commodities. The best engineers leave the body shop for companies that treat them as people. What remains is the engineers who could not get a better position.

This creates a negative selection spiral: the vendor rotates out the good engineers (either voluntarily or because the engineer quits), replaces them with weaker engineers, and the client's project quality declines. The client complains about quality. The vendor promises to "upgrade the team." The upgrade is another engineer who will be rotated out in 6 months.

No investment in engineer growth

Staffing firms that rotate engineers every 6 months have no incentive to invest in their technical growth. Training costs money. An engineer who gets trained and then leaves for a competitor is a loss. So the firm does not train. The engineers stagnate. They leave for firms that invest in their growth. The attrition cycle continues.

What 48% Attrition Costs the Client

Knowledge transfer on repeat

Each departing engineer takes undocumented context with them. The new engineer spends 2-3 months ramping up. During ramp-up, they operate at 50% productivity and consume senior team members' time through questions and pairing. For a 5-person team losing 1-2 engineers per year, you are permanently in ramp-up mode. At any given time, 20-40% of the team is below full productivity.

The annualized cost: 2 engineers × 3 months ramp-up × 50% productivity loss × $50-100/hour = $48,000-$96,000 in reduced output per year. That is before counting the senior engineer time consumed by onboarding the replacements.

Team cohesion destruction

Software engineering is a team sport. Engineers who have worked together for years develop shared understanding: coding conventions, architectural patterns, debugging instincts, and communication shortcuts. A team with 48% annual turnover never develops this cohesion. It is permanently a group of individuals, not a team.

The performance gap between a cohesive team and a collection of individuals is well-documented. Google's Project Aristotle found that team psychological safety — built through stable relationships — is the #1 predictor of team effectiveness. You cannot build psychological safety when half the team changes every year.

Vendor management overhead

Each rotation triggers: vendor communication about the change, review of the replacement's resume, interview with the replacement, transition planning, knowledge transfer sessions, and 2-3 months of closer supervision until the new engineer is up to speed. For the client's product manager or engineering lead, each rotation consumes 20-40 hours of management time.

At 2 rotations per year on a 5-person team, that is 40-80 hours/year of vendor management overhead driven entirely by attrition. At $80-$150/hour for the client's internal manager, that is $3,200-$12,000/year in management cost — not counting the opportunity cost of what that manager would have done with those hours.

Why Our Attrition Is Different

Our model is not utilization-driven. We do not rotate engineers to higher-paying projects because our engagements are structured as long-term partnerships, not resource placements.

We do not optimize for utilization. When an engineer is assigned to HeyTutor, they work on HeyTutor. For 9 years, in this case. They are not pulled to a new project because a new client offered $10/hour more. Our revenue model is based on stable retainers, not maximizing hourly rate per engineer.

We invest in engineer growth. Our engineers who built Laravel applications 5 years ago now build AI products. The engineers who built Nautical Commerce's Django marketplace now work on healthcare platforms. The technical growth keeps the work interesting. Interesting work retains engineers.

We assign engineers to domains they care about. An engineer who is passionate about FinTech works on FinTech projects. An engineer who loves mobile development builds mobile apps. Matching interest to assignment is not something utilization-optimized firms can do — they assign whoever is available. We assign whoever is right.

We treat engineers as the product, not as the commodity. Our clients stay for 3+ years because the engineers are excellent. If we rotated them, the clients would leave. Our business model depends on retention at both ends: engineer retention and client retention are the same thing.

How to Evaluate Augmentation Partners

Ask about tenure

"What is the average tenure of your engineers on client projects?" If the answer is "6-12 months" or "it varies," that is 48% attrition territory. If the answer is "our average engagement is 3+ years," verify it with references.

Ask about rotation policy

"Under what circumstances would you substitute an engineer on my project?" The right answer: "Only if the engineer leaves the company or you request a change." The wrong answer: "We reserve the right to substitute equivalent resources." That is the utilization-driven rotation clause.

Ask for named engineers before signing

"Who specifically will work on my project?" If the vendor cannot name the engineers before the contract, the team will be assembled from the available bench after signing. You do not know who you are getting. The bait-and-switch risk is high.

Check client retention

Vendors who retain engineers retain clients. Ask: "What percentage of your clients have been with you for 2+ years?" A firm with high engineer attrition also has high client attrition. The two are directly correlated.

Our numbers: HeyTutor (9 years), MyFlyRight (10 years), Greek House (4 years), Snapwire (2.5 years), Ripe (5 years). Those are not cherry-picked. Those are our major engagements. The pattern is the proof.

The Math

A 5-person augmented team at $50/hour with 48% annual attrition:

Direct cost: 5 × $50 × 160 × 12 = $480,000
Attrition cost (knowledge loss, ramp-up, management): ~$96,000-$144,000/year
Effective cost: $576,000-$624,000 (20-30% above invoice)

A 5-person augmented team at $70/hour with <10% annual attrition:

Direct cost: 5 × $70 × 160 × 12 = $672,000
Attrition cost: ~$10,000-$20,000/year (rare single rotations)
Effective cost: $682,000-$692,000

The difference is $58,000-$68,000 — about 10%. But the stable team ships more, breaks less, and requires less management. The total value delivered per dollar is higher with the stable team despite the higher hourly rate.

$50-99/hour with team stability is a better deal than $40/hour with 48% annual churn. The invoice is higher. The outcome is better. The total cost is comparable.

Talk to us →

Last updated April 14, 2024

Older
62% of Security Teams Say 25%+ of Alerts Are False Positives Newer
The True Cost of Outsourcing Is 20% More Than the Quote

Cloud Cost Waste: $44.5B Wasted in 2025

Dennis Vorobyov — Wed, 24 Jun 2026 01:26:54 +0000

Harness surveyed 1,200 FinOps practitioners for their 2025 State of FinOps report. The headline: 21% of enterprise cloud spend is waste. Flexera's State of the Cloud 2025 puts the number at 28%. Either way, we are talking about tens of billions of dollars globally — resources provisioned, running, and billed for work that is not happening.

55% of developers surveyed said their cloud commitments (reserved instances, savings plans) are based on guesswork. Not forecasting. Not usage data. Guesswork.

I run an engineering studio that deploys on AWS, GCP, and Hetzner. We see cloud waste on almost every client engagement we join. Not because the teams are careless. Because cloud billing is designed to be opaque, and nobody is incentivized to watch it.

Where the Waste Hides

Dev/staging environments that never shut down. Every project spins up dev and staging servers. They run 24/7. The development team works 8-10 hours per day, 5 days per week. That is 50 hours of use and 118 hours of idle time. The bill does not differentiate.

Over-provisioned production. The team provisioned for peak traffic 18 months ago. Traffic is 40% below peak now. Nobody resized the instances because "what if traffic spikes again?" The cloud provider is happy to keep billing for capacity you do not use.

Orphaned resources. A developer spun up an RDS instance for testing. The feature was cancelled. The instance is still running. Nobody remembers it exists. The bill goes to the infrastructure line item and nobody questions it because it is a rounding error. Multiply by 50 orphaned resources across 3 years and the rounding errors become real money.

Unused reserved instances. The team bought 1-year reserved instances for a workload that was decommissioned 4 months in. 8 months of paid-for capacity with no workload running on it.

What We Do Differently

Right-size from the start

We deploy production services with monitoring from day one. Not just uptime monitoring. Resource utilization monitoring: CPU, memory, network, storage IOPS. After 2 weeks of real traffic data, we right-size the instances to match actual usage with a 30% headroom buffer. Not the 200% buffer that "just in case" provisioning creates.

Auto-scaling as default

For web applications with variable traffic, auto-scaling is not a nice-to-have. It is the default. Scale up when traffic increases. Scale down when it drops. Pay for what you use. Nautical Commerce processes 200K+ monthly transactions with traffic patterns that vary significantly by time of day and day of week. Fixed provisioning for peak would waste 60% of capacity during off-peak hours.

Monthly cost reviews

We include cloud cost review in the monthly engineering report for every client. Not a finance report. An engineering report: which services cost what, which costs are growing, which costs can be reduced. Engineers who see the bill make different provisioning decisions than engineers who never see it.

Hetzner for the right workloads

Not everything needs AWS. Our own website runs on a Hetzner VPS ($8.60/month) with Cloudflare CDN in front. The equivalent on AWS (EC2 + CloudFront + Route 53) would cost $50-$100/month. For a static site serving HTML, the cheaper option is the right option.

We deploy client applications on AWS or GCP when the workload requires it: managed databases, auto-scaling, global distribution, compliance requirements (HIPAA, SOC2). We deploy on Hetzner when it does not. The decision is based on requirements, not on which cloud provider has the best enterprise sales team.

The Fix

Cloud waste is an engineering discipline problem, not a tools problem. The teams that waste the least are teams that: monitor resource utilization from day one, right-size after real traffic data (not estimates), auto-scale variable workloads, shut down dev/staging environments outside business hours, audit for orphaned resources monthly, and review cloud costs as an engineering metric.

These practices cost nothing to implement. They save 15-25% of cloud spend. On a $10,000/month cloud bill, that is $1,500-$2,500/month. On a $100,000/month bill, that is $15,000-$25,000/month. The savings compound every month the practices are in place.

Our DevOps services include cloud cost optimization as a standard part of infrastructure setup. Not as a separate engagement. As a part of doing the infrastructure work correctly from the start.

Talk to us →

Last updated September 28, 2025

Older
Scope Creep Adds 20-40% to Outsourced Projects Newer
80% of Federal IT Spend Goes to Maintaining Old Systems

Compliance Burden 2025: GDPR, HIPAA, EU AI Act

Dennis Vorobyov — Tue, 23 Jun 2026 01:26:54 +0000

In 2018, GDPR took effect. In 2020, CCPA went live. In 2023, the SEC adopted cybersecurity disclosure rules. In 2024, the EU AI Act was signed. In 2025, HIPAA's mandatory security rule updates arrived. In 2026, the EU AI Act's high-risk system provisions become enforceable.

Each regulation adds requirements: data mapping, consent management, audit trails, access controls, incident response plans, risk assessments, impact analyses, documentation, and reporting. Each one assumes the others exist. None of them reduce the burden of the others.

McKinsey found that organizations with legacy systems face 4.7x higher compliance overhead than those with modern architectures. PwC's Global Risk Survey found that 67% of organizations say regulatory compliance costs have increased "significantly" over the past 3 years. Thomson Reuters estimates that global regulatory spending across all industries exceeds $270 billion annually.

We build software for FinTech, healthcare, and legal tech clients. Compliance is not a feature we add at the end. It is the architecture we start with.

The Regulatory Stack

GDPR (EU, 2018)

Applies to any company that processes data of EU residents. Requirements: lawful basis for processing, data subject rights (access, erasure, portability), Data Protection Officer appointment, breach notification within 72 hours, data processing agreements with vendors, privacy impact assessments.

We build with GDPR from our Lisbon headquarters. Our privacy policy and cookie policy are GDPR-native. Every application we build for EU clients includes: consent management, data subject access request handling, encryption at rest and in transit, audit logging, and data retention policies.

HIPAA (US Healthcare, updated 2025)

Applies to covered entities and their business associates handling protected health information (PHI). The 2025 mandatory Security Rule updates add: encryption requirements (previously "addressable," now mandatory), MFA for ePHI access, network segmentation, and 72-hour security incident notification.

We build healthcare applications for RiseMD and WinitClinic on HIPAA-eligible infrastructure. BAA chain maintained from cloud to application. PHI encrypted at rest and in transit. Audit logging for every data access.

PCI DSS (Payments, v4.0)

Applies to anyone processing, storing, or transmitting cardholder data. Version 4.0 (effective 2025) adds: targeted risk analysis for security controls, enhanced authentication requirements, and more granular access controls.

Float Financial operates PCI-certified payment card programs. Nautical Commerce processes 200K+ monthly transactions through Stripe. Our approach: delegate PCI scope to certified processors (Stripe, Adyen) wherever possible, minimize cardholder data in our systems, and implement PCI requirements for any data we must handle.

EU AI Act (2024, phased enforcement through 2026)

The world's first comprehensive AI regulation. High-risk AI systems (healthcare, employment, credit scoring) face requirements: risk management systems, data governance, technical documentation, transparency obligations, human oversight, and conformity assessment.

This directly affects our AI development work. AI features in healthcare applications, recruitment tools, and financial products will require documented risk assessments, bias testing, and ongoing monitoring. We are building these practices into our AI engineering workflow now, before enforcement begins.

SOC2 (Service Organization Controls)

Not a regulation but a trust framework that clients increasingly require. SOC2 Type II attestation requires demonstrating operational security controls over a 6-12 month audit period. Controls cover: security, availability, processing integrity, confidentiality, and privacy.

For clients pursuing SOC2, we build with SOC2-aligned practices: access management, change management, incident response, monitoring, and vendor management. The architecture supports the attestation before the auditor arrives.

Why Compliance Compounds

Each regulation was designed independently. GDPR does not reduce HIPAA requirements. PCI DSS does not satisfy SOC2 controls. The EU AI Act adds requirements on top of GDPR, not instead of it.

For a company building a healthcare AI product that processes EU patient data and accepts payments, the compliance stack is: GDPR + HIPAA + PCI DSS + EU AI Act. Each regulation requires: its own risk assessment, its own documentation, its own audit trail, its own incident response procedure.

The controls overlap significantly. Encryption satisfies GDPR, HIPAA, PCI DSS, and SOC2 simultaneously. Access controls are required by all of them. Audit logging is universal. But the documentation, assessment, and reporting requirements are separate. You cannot submit one impact assessment to four regulators.

The Architecture Advantage

McKinsey's 4.7x overhead for legacy systems exists because legacy systems were built before these regulations existed. Adding GDPR consent management to a system designed in 2008 requires retrofitting the data model, the UI, the API, and the storage layer. Adding the same to a system designed in 2025 requires configuring what was already built in.

Modern architectures reduce compliance cost through:

Role-based access control (RBAC) from day one. When access controls are built into the first sprint, adding a new regulation's access requirements is a configuration change, not an architecture change.

Encryption at rest and in transit by default. TLS for all connections. Field-level encryption for sensitive data. Key management through cloud provider services (AWS KMS, GCP KMS). This satisfies GDPR, HIPAA, PCI, and SOC2 encryption requirements simultaneously.

Audit logging as infrastructure. Every data access, every authentication event, every permission change is logged. The logs support compliance reporting for any regulation. Without audit logging, generating compliance evidence for a single regulation requires manual reconstruction. With it, the evidence is automatic.

Automated compliance testing in CI/CD. Security scans, dependency checks, and configuration validation run on every build. Compliance drift is caught in the pipeline, not in the annual audit.

What We Build

Every application we build for regulated industries starts with compliance architecture:

For healthcare: HIPAA-eligible cloud, BAA chain, PHI encryption, MFA, audit logging, breach notification procedures. See medical software development.

For FinTech: PCI scope delegation, PSD2 SCA implementation, KYC/AML workflow support, transaction monitoring hooks. See FinTech development.

For legal tech: GDPR Article 9 awareness, data retention automation, court jurisdiction routing, evidence chain integrity. See legal software development.

For AI products: EU AI Act risk categorization, bias testing framework, transparency documentation, human-in-the-loop architecture. See AI development services.

The compliance burden is real and compounding. The answer is not to hire more compliance officers. It is to build systems where compliance is a property of the architecture, not a layer added on top.

Talk to us →

Last updated January 19, 2025

Older
When Your Outsourced Team Leaves, the Knowledge Leaves Too Newer
Supply-Chain Breaches Cost $4.91M and Take 267 Days to Contain

CTO Decision Anxiety: 73% Report It

Dennis Vorobyov — Sun, 21 Jun 2026 13:26:54 +0000

Nash Squared's 2024 Digital Leadership Report found that 73% of CTOs and CIOs report increased decision anxiety compared to the prior year. The causes, in order: the speed of AI advancement (cited by 68%), cybersecurity threat evolution (54%), and talent market uncertainty (49%). Three forces, all moving faster than any individual can track, all requiring decisions with multi-year consequences.

I am a CEO, not a CTO. But I make the same category of decisions: which technologies to bet on, which clients to pursue, which team structure to build. The anxiety is not about intelligence. It is about the gap between the speed of change and the speed of understanding.

Why Decision Anxiety Is Worse in 2025-2026

AI moves faster than due diligence

In 2023, the AI choice was "GPT-4 or wait." In 2025, the choice is: GPT-4o or o1 or Claude 3.5 or Claude 4 or Gemini 2.5 or Llama 3 or Mistral Large or a fine-tuned open-source model. Each has different cost profiles, latency characteristics, accuracy on specific tasks, and vendor lock-in implications. The evaluation cycle for a proper model comparison is 2-4 weeks. By the time you finish, a new model has launched that changes the calculus.

94% of companies see no meaningful ROI from AI partly because decision anxiety leads to analysis paralysis. The CTO cannot commit to a model because a better one might launch next month. The AI project stalls. The competitor who picked a model 3 months ago — even if it was not the optimal choice — has shipped a product and is iterating.

The correct response to AI decision anxiety is not more evaluation. It is a bias toward integration with provider-switching architecture. Build the application so the LLM provider is a pluggable module. Choose a model. Ship. Switch if a better option emerges. The architectural decision (how you integrate) matters more than the model decision (which provider you choose today).

Security threats compound faster than defenses

The average data breach costs $10.22M in the US. Supply-chain attacks take 267 days to detect. Shadow AI adds $670K to breach costs. 16% of breaches now involve AI-enabled attacks.

The CTO must decide: how much to invest in security, which threats to prioritize, which tools to deploy, and which risks to accept. Every decision has a failure mode. Invest too little and you are the next breach headline. Invest too much and the board asks why engineering velocity dropped.

The anxiety is rational. The consequences are asymmetric. A correct security investment is invisible (nothing bad happens). An incorrect one is catastrophic (the breach happens). The CTO gets no credit for preventing attacks that never occurred. They get full blame for the one that does.

Talent decisions have 18-month consequences

Hiring an engineer is an 18-month commitment: 95 days to hire, 3-4 months to ramp, and 12 months before you know whether the hire was right. Choosing an outsourcing vendor is a 6-12 month commitment with a 59% failure rate from skill mismatch.

The CTO must make both decisions — build or buy, hire or partner, onshore or nearshore — with incomplete information and consequences that play out over 1-2 years. The anxiety comes from knowing that a wrong decision costs $150,000-$250,000 per engineer replacement and 6+ months of lost momentum.

What Decision Anxiety Produces

Analysis paralysis

The most common response to decision anxiety is to delay decisions by requesting more analysis. "Let's do a deeper evaluation of the three AI providers." "Let's get another vendor proposal before deciding." "Let's pilot for 3 more months before committing."

Each delay is individually reasonable. Collectively, they produce a 6-12 month evaluation cycle for decisions that should take 2-4 weeks. The competitor who decided faster ships faster. The market does not wait for due diligence to complete.

Consensus-seeking that produces mediocrity

Another anxiety response: ask everyone's opinion and pick the option nobody objects to. The problem is that the option nobody objects to is usually the option that is neither the best nor the worst — it is the safe, mediocre middle. Choosing React because "everyone knows it" instead of Vue because it fits the project better. Choosing AWS because "nobody gets fired for choosing AWS" instead of Hetzner because the workload does not need AWS.

Architecture decisions made by committee optimize for political safety, not technical excellence. The CTO's job is to make the call, take the risk, and be accountable for the outcome. Decision anxiety undermines that accountability by distributing it across a committee that cannot be held responsible.

Over-engineering as insurance

"If we build it on microservices, we will be ready for any scale." "If we choose the most expensive AI model, we will not be caught with insufficient quality." "If we hire 3 more engineers than we need, we will have buffer for attrition."

Each of these is an anxiety-driven decision that trades money for certainty. Premature microservices add operational complexity that costs more than the scale they prepare for. The most expensive AI model is often not the most appropriate. Buffer hiring at $150K-$250K per position is an expensive insurance policy.

What Actually Helps

A framework, not a feeling

The antidote to decision anxiety is a decision framework that reduces the emotional weight of each choice.

For technology decisions: "Will this be easy to reverse if we are wrong?" Reversible decisions (which AI model, which cloud region, which UI framework) should be made quickly. Irreversible decisions (which database for a 5-year product, which programming language for the core platform) deserve more evaluation. Most decisions are more reversible than they feel.

For vendor decisions: "Can we test before committing?" A paid trial sprint at $5,000-$15,000 resolves 6 months of vendor evaluation anxiety in 2 weeks. The trial produces data. The evaluation produces opinions. Data beats opinions.

For hiring decisions: "What is the cost of being wrong versus the cost of delay?" If the cost of a wrong hire is $150K-$250K and the cost of a 6-month vacancy is $120K+, the math favors faster decisions with strong onboarding rather than exhaustive interview processes.

External technical counsel

The loneliest aspect of being a CTO is making architectural decisions with nobody to challenge your reasoning. The board does not understand the technical trade-offs. The engineering team defers to your authority. The vendors have conflicts of interest.

A fractional CTO or external technical advisor provides the sounding board. Not to make the decision for you. To challenge the reasoning, surface risks you have not considered, and confirm that the decision is defensible even if the outcome is uncertain.

Our co-founder has served as fractional CTO for HeyTutor (9 years), Greek House (4 years), and Ripe (5 years). In each case, the value was not just engineering execution. It was having someone who could absorb some of the decision anxiety by providing experienced perspective on the trade-offs.

Smaller, faster decisions

Break the big decision into smaller ones. "Choose the AI platform for the next 3 years" is anxiety-inducing. "Choose the AI platform for the next feature and architect for switching" is manageable. The smaller decision has lower stakes, shorter time horizon, and faster feedback.

Ship the feature on GPT-4o. Measure the result. If the result is good, continue. If not, switch to Claude. The architecture supports the switch because you built it that way from the start.

This is how we work. We do not ask clients to commit to 18-month technology decisions on day 1. We make the best decision for the current sprint, build with switching in mind, and iterate based on real data. The anxiety dissolves when the decision horizon shortens from "the next 3 years" to "the next 3 sprints."

Talk to us →

Last updated July 7, 2024

Older
Time Zones Kill Distributed Teams. Nearshore Fixes It. Newer
35% of Developers Use 6-10 Tools Daily. The Debugging Tax Is Real.

US Data Breach Cost Hits $10.22M in 2025

Dennis Vorobyov — Sat, 20 Jun 2026 13:26:54 +0000

IBM has published the Cost of a Data Breach report for 19 consecutive years. The 2025 edition analyzed 604 real breaches across 16 countries and 17 industries. The numbers are the worst they have ever been.

Global average cost: $4.88M per breach. United States average: $10.22M. Healthcare average: $10.93M — the most expensive industry for the 14th consecutive year. Time to identify a breach: 194 days. Time to contain it: 292 days total. That is 10 months from breach to containment.

I run an engineering studio. We are not a cybersecurity firm. But every application we build handles data, and how we build it determines how vulnerable that data is.

The Numbers That Matter

Cost by country (top 5):

United States: $10.22M
Middle East: $8.75M
Canada: $5.40M
Germany: $5.31M
Japan: $4.53M

Cost by industry (top 5):

Healthcare: $10.93M
Financial services: $6.08M
Pharmaceuticals: $5.10M
Technology: $5.07M
Energy: $4.72M

Cost by attack vector:

Phishing: $4.88M (most common)
Stolen credentials: $4.81M (second most common)
Supply-chain compromise: $4.91M
AI-enabled attacks: $5.30M (16% of breaches now involve AI)

What reduces cost:

Security AI and automation: saved $2.22M per breach
Incident response team and tested plan: saved $1.49M
DevSecOps adoption: saved $1.68M
Encryption (data at rest and in transit): saved $1.09M

The Engineering Connection

Most breach reports focus on the security team: incident response, threat detection, compliance. But the most impactful decisions happen during software development, months or years before the breach occurs.

Architecture decisions compound

A database designed without field-level encryption is vulnerable from day one. An API without rate limiting is an invitation for credential stuffing. An admin panel without MFA is a breach waiting to happen. A third-party dependency that has not been updated in 2 years carries every vulnerability discovered since the last patch.

These are not security team decisions. They are engineering decisions made during sprint planning. The IBM data is clear: DevSecOps adoption (security integrated into the development process) saves $1.68M per breach. That is not a security tool. That is a development practice.

Dependencies are the new attack surface

16% of breaches now involve the software supply chain. Attackers compromise a library, an SDK, or a build tool, and every application that depends on it becomes vulnerable. Supply-chain breaches cost $4.91M on average and take 267 days to contain.

We run automated dependency scanning in every CI/CD pipeline. npm audit, Snyk, or Dependabot on every build. When a vulnerability is published in a dependency we use, we know the same day. Not the same quarter. The same day.

Our own website runs on Astro with every dependency audited. When we found 9 moderate vulnerabilities in transitive dependencies during our last audit, we traced each one, confirmed they were dev-time-only (locked in @astrojs/check and @sanity/cli), and documented the decision. That is what dependency management looks like.

HTTPS and headers are not optional

Every application we deploy uses HTTPS with proper TLS configuration. Content Security Policy headers are deployed in report-only mode first, then enforced. Strict-Transport-Security ensures browsers never connect over plain HTTP.

These are not advanced security measures. They are baseline engineering practices. IBM data shows that encryption (at rest and in transit) saves $1.09M per breach. CSP headers prevent cross-site scripting. HSTS prevents downgrade attacks. These cost nothing to implement and protect against the most common attack vectors.

What We Do About It

We are a software development studio, not a security vendor. But every application we build includes security practices that directly reduce breach risk:

Security-first architecture. MFA on admin interfaces. Field-level encryption for sensitive data. Role-based access control with least-privilege defaults. Audit logging for every data access. These are not add-ons. They are built into the first sprint.

Automated dependency scanning. Every CI/CD pipeline includes vulnerability scanning. Every dependency update is tested. Every critical vulnerability is patched within the sprint it is discovered.

CSP and security headers. Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options. Deployed on every application.

HIPAA compliance when required. For healthcare clients like RiseMD and WinitClinic, we deploy on HIPAA-eligible infrastructure (AWS, GCP), sign BAAs, implement mandatory encryption, MFA for ePHI access, and maintain audit trails. The IBM data shows healthcare breaches cost $10.93M. The compliance overhead is not optional.

Regular security audits. We run npm audit, OWASP checks, and CSP validation on every build. For production applications, we recommend annual penetration testing through a third-party security firm.

The $2.22M Savings

IBM found that organizations using security AI and automation saved $2.22M per breach. That sounds like a sales pitch for security tools. What it actually means is: organizations that automated their security practices — scanning, monitoring, alerting, response — caught breaches faster and contained them more cheaply.

Automated dependency scanning is security automation. CI/CD pipelines that run security checks on every commit are security automation. Alert systems that notify the team when an anomaly is detected are security automation. These are engineering practices, not security products.

The average breach takes 292 days to contain. Organizations with automated security practices cut that by 108 days. 108 days of breach containment is millions of dollars in reduced impact.

The Business Case for Engineering Quality

$10.22M is the average US breach cost. $10.93M for healthcare. $4.91M for supply-chain attacks. These numbers make the case for security-conscious engineering better than any sales pitch ever could.

Every hour spent on security-first architecture, dependency scanning, CSP headers, and encrypted data at rest is an hour invested against a $4.88M global average loss. The ROI calculation writes itself.

We build software with these practices from the first commit. Not because we are a security company. Because we are an engineering company that understands what the data says about the cost of not doing it.

Talk to us →

Last updated March 15, 2026

Older
Nearshore Software Development: The 2026 Guide for European and US Buyers Newer
How to Choose a Software Development Partner: A Framework from the Other Side of the Table

Developer Productivity: You Can't Measure It with One Number

Dennis Vorobyov — Fri, 19 Jun 2026 13:26:54 +0000

McKinsey published "Yes, you can measure software developer productivity" in August 2023 and the industry lost its mind. The backlash from engineers, engineering leaders, and productivity researchers was immediate and sustained. Kent Beck, co-author of the Agile Manifesto, called the framework "actively dangerous." Gergely Orosz, author of The Pragmatic Engineer, wrote a detailed rebuttal. Dan North called it "the McKinsey 'Developers are like bricklayers' article."

The backlash was not about whether productivity can be measured. It was about what McKinsey proposed measuring and the perverse incentives those measurements create.

I manage 35-50 engineers across multiple client projects. I measure team performance constantly. But I do not use a single number. Nobody should.

Why Single-Number Metrics Fail

Lines of code

The most obvious bad metric and the easiest to dismantle. A developer who writes 1,000 lines of code per day is not 10x more productive than one who writes 100. They might be 10x less productive — writing verbose, poorly structured code that a better engineer would express in 100 lines.

The best engineering work is often subtractive. Deleting 500 lines of dead code. Replacing a 200-line function with a 30-line library call. Refactoring a module so the next feature requires 50 lines instead of 500. By the lines-of-code metric, these improvements look like negative productivity.

Nobody serious uses lines of code anymore. But the instinct behind it — measuring output volume — persists in more sophisticated disguises.

Story points completed

Story points were designed for estimation, not measurement. They are team-relative, not absolute. A team that estimates generously completes more points. A team that estimates conservatively completes fewer. Comparing point velocity between teams, or using it as a productivity metric for individuals, produces exactly the wrong incentives: inflate estimates, cherry-pick easy tickets, avoid complex work that takes longer than the points suggest.

The creator of story points, Ron Jeffries, has explicitly said they should not be used for productivity measurement. "Story points are for planning, not for management," he wrote. The industry adopted his tool and used it for the opposite of its intended purpose.

Pull requests per week

PRs per week incentivizes small PRs. Small PRs are generally good for code review. But a developer who splits a feature into 10 tiny PRs to improve their metrics is not more productive than one who submits 2 well-scoped PRs that accomplish the same work. They are gaming the metric and creating 5x the review overhead.

DORA metrics (misapplied)

Google's DORA metrics — deployment frequency, lead time, change failure rate, time to restore — are excellent team-level indicators of software delivery performance. They are not individual productivity metrics. A team that deploys 50 times per week has a healthy pipeline. An individual who creates 50 deployments per week might be introducing instability.

DORA explicitly measures at the team level. The researchers who developed the metrics warn against applying them to individuals.

What Actually Measures Productivity

Outcome over output

The question is not "how much did the engineer produce?" It is "what business outcome did the engineering produce?"

RiseMD: 20X ROI from $160K in marketing spend. That is a measurable outcome from the platform we built. The number of story points, PRs, or deploys that produced it is irrelevant. The business outcome is the metric.

Greek House: went from releases every few months to same-day deploys, which enabled Inc. 5000 growth and eventually an acquisition. The outcome was business growth unlocked by engineering capability. No single-number productivity metric captures that.

Ripe: acquired by Hungry after 5 years of development. The acquirer's engineers could read, understand, and extend the codebase. That code quality — not the volume of code — is what made the exit possible.

Delivery against commitment

Can the team deliver what it committed to in the sprint? Not story points. Not velocity. The actual working software that was planned, built, tested, and shipped.

A team that commits to 5 features and delivers 5 is performing well. A team that commits to 10 and delivers 6 (completing 120 story points along the way) is performing poorly despite the higher point count. The commitment-to-delivery ratio is a better signal than any volume metric.

We track this on every client engagement. Our sprint review shows: what was planned, what was delivered, and what slipped. The ratio tells us whether the team is healthy, overcommitted, or struggling. No single number. A conversation about the gap between plan and reality.

Quality signals over time

Defect rate, change failure rate, and time-to-resolve are quality signals that correlate with sustainable productivity. A team that ships fast but creates bugs is not productive — they are generating rework that consumes future productivity.

Track defect rate per sprint. If it is trending up, the team is cutting corners (possibly under pressure from unrealistic deadlines or from burnout). If it is trending down, the team's practices are improving. The trend matters more than any single data point.

Developer experience surveys

Ask the developers. "On a scale of 1-5, how productive do you feel this sprint?" "What blocked you?" "What would make you more productive?" Self-reported productivity correlates with actual output better than any external metric (multiple studies from Microsoft Research confirm this).

DX (Developer Experience) is an emerging field precisely because the research shows that developer satisfaction, perceived productivity, and actual delivery are strongly correlated. Happy developers who feel productive are productive. Unhappy developers who feel blocked are not. The survey is cheaper and more accurate than any dashboard of computed metrics.

The McKinsey Problem

McKinsey's framework proposed measuring individual developers on "inner loop" and "outer loop" activities, contribution analysis, and talent capability assessments. The framework is internally consistent. The problem is the incentive structure it creates.

When you measure inner-loop speed (how fast a developer writes and tests code), developers optimize for speed over quality. When you measure outer-loop throughput (how fast code moves through review and deployment), developers pressure reviewers to approve faster. When you measure contribution relative to peers, developers compete instead of collaborate.

The engineering teams that perform best — Google's Project Aristotle data confirms this — are teams with high psychological safety, where members help each other, share knowledge freely, and are not afraid to admit mistakes. Individual productivity measurement undermines psychological safety by creating competitive dynamics that punish collaboration.

How We Measure at EltexSoft

We do not measure individual developer productivity. We measure team delivery against client commitments.

Sprint delivery ratio. What percentage of committed work was delivered? Target: 85-95%. Below 80% consistently means the team is overcommitting or blocked. Above 95% consistently means the team is undercommitting (sandbagging).

Client satisfaction. Does the client feel the team is performing? This is subjective. It is also the metric that determines whether the engagement continues. A team with perfect velocity metrics but an unhappy client is failing.

Code quality trends. Technical debt trajectory (improving or declining), defect rate trend, test coverage trend, deployment confidence. These are lagging indicators of practices, not leading indicators of productivity. But they reveal whether the team is building sustainably.

Retention. Our engineers stay for years. High retention is a proxy for healthy engineering culture, interesting work, and sustainable pace. The teams that retain people are the teams that perform well. Attrition is a productivity metric — the most honest one.

Business outcomes. Ultimately, the question is whether the engineering produced business value. HeyTutor grew from a one-page spec to a marketplace with 10,000+ tutors and LAUSD as a client. Nautical Commerce raised $30M and was acquired. Greek House made Inc. 5000 and was acquired. These outcomes are not captured by story points, PRs per week, or lines of code. They are captured by whether the engineering was good enough to make the business succeed.

You cannot measure developer productivity with a single number. You can measure team health, delivery consistency, quality trends, and business outcomes. The aggregate of these signals tells you more than any McKinsey framework ever will.

Talk to us →

Last updated September 29, 2024

Older
40% of Engineering Leaders Now Manage More People Than Last Year Newer
Premature Microservices Are the New Technical Debt

Developer Retention: Only 24% Happy at Work

Dennis Vorobyov — Thu, 18 Jun 2026 01:26:54 +0000

Stack Overflow surveys over 65,000 developers annually. The 2025 edition found that only 24% are happy at work. 75% are complacent or unhappy. And 92% plan to look for a new job within the next 12 months.

That last number should alarm anyone who manages engineers. 92% are looking. Not "open to opportunities." Looking.

I run an engineering studio with a team that has been together for years. Our average client engagement is 3+ years. I have opinions about why developers stay and why they leave.

The Data

Stack Overflow (2025, n=65,000+):

24% happy at work
48% complacent ("it's fine")
27% unhappy
92% plan to look for a new job within 12 months

Haystack Analytics (2025):

83% of developers report burnout
Top causes: unrealistic deadlines (59%), technical debt (43%), unclear requirements (38%)
40% say they have considered leaving the tech industry entirely

Reveal (2025 Developer Recruitment Report):

Average developer tenure at a company: 2.3 years
Tenure has been declining for 5 consecutive years
The cost of each departure: $150K-$250K (SHRM methodology)

Why They Leave

Bad code

This is the one nobody talks about publicly but every developer talks about privately. Working in a legacy codebase with no tests, no documentation, and no plan to improve it is miserable. Every feature is a fight against the existing code. Every deployment is a risk. Every Monday morning feels like walking into a mess someone else made.

43% of developers cite technical debt as a burnout factor (Haystack). I believe that number is low. In my experience, technical debt is the root cause of most developer unhappiness, even when the stated reason is something else ("unrealistic deadlines" often means "the codebase is so fragile that everything takes 3x longer than it should").

The companies that retain engineers are the companies that invest in code quality. That means 15-20% of sprint capacity dedicated to debt reduction, CI/CD from day one, test coverage as a non-negotiable, and code reviews that are learning opportunities, not gatekeeping rituals.

No autonomy

Engineers who are told exactly what to build and exactly how to build it are not engineers. They are typists. Senior developers want to understand the problem, propose solutions, and make architectural decisions. When the product manager dictates implementation details and the CTO micromanages pull requests, the best engineers leave first.

At EltexSoft, our technical leads serve as fractional CTOs for clients. That means our engineers make architecture decisions, choose libraries, design APIs, and own the technical direction. HeyTutor's entire technical stack was chosen and implemented by our team. The founders trusted us with the technical decisions because that is what they hired us for.

No impact visibility

"I shipped 47 pull requests this quarter" is not impact. "The feature I built increased user retention by 12%" is impact. Developers who cannot see how their work affects the business feel like cogs. Developers who understand the business outcome of their code feel like owners.

Every case study we publish includes engineering outcomes tied to business results. RiseMD: 20X ROI from the platform we built. Ripe: acquired by Hungry. Greek House: Inc. 5000 and acquired. Our engineers know what their code produced. That matters.

Compensation misalignment

This is the obvious one but not always the most important. Stack Overflow data shows compensation is the #3 reason developers leave, behind "wanting to learn new technologies" (#1) and "wanting better work-life balance" (#2). Compensation matters, but it is not sufficient. A developer earning $200K at a company with terrible code, no autonomy, and no visible impact will still leave.

The Replacement Cost

SHRM's replacement cost methodology for senior roles includes: recruiting costs ($15K-$30K), interviewing time (40-60 hours of team time), signing bonus and relocation ($10K-$30K), onboarding (2-4 months at reduced productivity), lost output during vacancy (95 days × daily rate), and team disruption (velocity drops 15-25% when a team member leaves).

Total: $150,000-$250,000 per departure.

For a 10-person engineering team with the industry-average 2.3-year tenure, you are replacing 4-5 engineers per year at $150K+ each. That is $600K-$1.25M annually in churn costs. Most companies do not track this number. They should.

What Retains Engineers

Based on running a team where the average tenure exceeds the industry average by a wide margin:

Good code. Engineers want to work in codebases they are proud of. That means modern frameworks, test coverage, CI/CD, clean architecture, and a plan for technical debt. MyFlyRight has been maintained for 10 years with no major rewrites. That is an engineering environment people want to work in.

Interesting problems. Marketplace matching algorithms, image processing pipelines for millions of photos, HIPAA-compliant telemedicine platforms, EU regulatory compliance automation. Our engineers work on real products with real users, not internal tools nobody cares about.

Stability. Long-term client engagements mean engineers do not get shuffled between projects every 3 months. They learn a domain, build expertise, and see the impact of their work over years.

Technical growth. Engineers who worked on Laravel projects 3 years ago now build AI products. The stack evolves. The skills grow. The work stays challenging.

Respect. No "rockstar developer" culture. No crunch time as default. No expectation that engineers are available at midnight. Professional engineering with professional boundaries.

The Business Implication

The 74% talent shortage gets all the headlines. But the 92% looking-to-leave number is more important. You can hire through a shortage with effort and money. You cannot retain through systematic unhappiness with more money alone.

The companies that retain engineers — and the studios that retain engineering teams — do it by caring about code quality, giving engineers autonomy, connecting work to business outcomes, and treating the profession with respect.

That is how we have kept our team together for 11 years.

Talk to us →

Last updated November 23, 2025

Older
80% of Federal IT Spend Goes to Maintaining Old Systems Newer
Why 70% of Software Projects Blow Their Budget

Engineering Burnout 2025: The Numbers

Dennis Vorobyov — Wed, 17 Jun 2026 13:26:54 +0000

LeadDev surveyed engineering managers and their teams for their 2025 State of Engineering Management report. 22% of engineers reported critical burnout. 24% reported moderate burnout. That is 46% of engineers experiencing meaningful burnout.

Haystack Analytics puts the number higher: 83% of developers report burnout. The difference depends on methodology and definition. LeadDev measures self-reported burnout severity. Haystack measures whether developers have experienced burnout symptoms. Either way, the numbers are bad.

I have run engineering teams for 11 years. I have seen burnout from the inside — both in my own team and in client teams we joined. The cause is rarely the work itself. It is the environment the work happens in.

What Drives Burnout

Expanded responsibilities, same headcount

65% of engineers report taking on more responsibilities without additional headcount (LeadDev). The 74% talent shortage means companies cannot hire. So existing engineers absorb the work. Backend developers start doing DevOps. Frontend developers handle design. Senior engineers do project management on top of coding.

Each additional responsibility reduces focus time. Engineers who spend 4 hours per day in meetings and context-switching have 4 hours per day to code. The same amount of feature work is expected. The result is longer hours, lower quality, or both.

Technical debt

43% of developers cite technical debt as a burnout factor (Haystack). Working in a legacy codebase where every change is fragile, every deployment is risky, and every sprint starts with "first we need to fix what broke" is exhausting.

The psychological weight of technical debt is underestimated by managers who do not write code. It is not just that the work takes longer. It is that the work feels pointless — fixing the same categories of bugs, working around the same architectural limitations, knowing that the system is getting worse despite your effort.

Unrealistic deadlines

59% cite unrealistic deadlines. This connects to the headcount problem. The same amount of work, fewer people, same deadline. The math does not work. Engineers know the math does not work. Management sets the deadline anyway. Engineers either crunch to meet it (burnout) or miss it (demoralization).

Software projects overrun by 45% on average. When the baseline estimate is already aggressive and the average overrun is 45%, the resulting schedule is a burnout generator.

AI tools are not the fix

AI coding tools were supposed to help. The data says otherwise. 84% of developers use AI tools but only 29% trust the output. METR found that AI tools made experienced developers 19% slower on complex tasks. Using an untrustworthy tool that occasionally speeds you up and frequently slows you down is not a burnout fix. It is an additional cognitive load.

What Actually Reduces Burnout

Reasonable team sizing

The math: if a product needs 6 engineers to deliver on time, staffing it with 4 means burnout. The talent shortage makes hiring hard. Retained engineering teams close the gap in 2-3 weeks instead of 95 days.

Snapwire needed 30 engineers. They had 20. We provided 10. The team was no longer understaffed. The work was no longer compressed into too few people.

Technical debt allocation

15-20% of every sprint goes to reducing debt. This is not a luxury. It is burnout prevention. Engineers who see the codebase improving feel progress. Engineers who watch it decay feel hopeless.

Scope discipline

Features ship in 2-week sprints. Scope is defined per sprint, not per quarter. When the sprint is full, additional requests go to the backlog. No exceptions. This protects engineering time and gives the team a sustainable rhythm.

Stable teams

Our average client engagement is 3+ years. Engineers work on the same product, with the same teammates, for years. They are not rotated between projects every 3 months. They build domain expertise and relationships that make the work easier and more rewarding.

HeyTutor: 9 years. MyFlyRight: 10 years. Greek House: 4 years. These are not just engagement durations. They are engineering environments where people stay because the work is sustainable.

The Retention Connection

Burnout drives attrition. 24% of developers are unhappy and 92% plan to look for a new job. The replacement cost is $150K-$250K per departure. The companies that prevent burnout retain engineers. The companies that cause burnout pay to replace them.

The cheapest engineer is the one who stays. The most expensive is the one who leaves and takes 6 months of context with them. Burnout prevention is not an HR initiative. It is a financial imperative.

Talk to us →

Last updated June 8, 2025

Older
62% of CTOs Can't Align IT with Business Goals Newer
Time-to-Hire for Engineers Hits 95 Days

Engineering Manager Overload: 40% More Reports

Dennis Vorobyov — Wed, 17 Jun 2026 01:26:54 +0000

LeadDev's 2025 State of Engineering Management report found that 40% of engineering leaders now manage more direct reports than they did a year ago. The average engineering manager oversees 8-12 engineers, up from 6-8 three years ago. The cause is not org growth. It is the talent shortage: companies cannot hire fast enough, so they stretch existing managers thinner instead of adding management capacity.

The result is predictable. Managers who should spend 30-40% of their time on strategic work (architecture reviews, technical roadmap, process improvement) spend 80%+ on people management: 1:1s, sprint planning, standups, performance reviews, conflict resolution, and the endless stream of Slack DMs that starts at 8 AM and does not stop until 7 PM.

I manage engineers for a living. My observation: the single most common reason engineering teams underperform is not bad engineers. It is overloaded managers.

The Numbers

LeadDev (2025):

40% of engineering leaders manage more people than last year
Average span of control: 8-12 direct reports (up from 6-8)
62% say they do not have enough time for strategic technical work
78% report that administrative tasks have increased

Gartner (2025):

Engineering manager turnover increased 23% year-over-year
The #1 reason for manager departure: workload exceeding capacity
Average tenure of engineering managers: declining for 3 consecutive years

Google's Project Aristotle and re:Work research:

Manager quality is the single strongest predictor of team performance
Teams with good managers are 25-30% more productive than teams with overloaded managers
The inflection point: managers with more than 9 direct reports show measurable decline in team satisfaction and output

Why 8-12 Direct Reports Breaks

1:1 meetings eat the calendar

A good 1:1 with a direct report takes 30-45 minutes every week or biweekly. At 10 direct reports with weekly 1:1s, that is 5-7.5 hours per week on 1:1s alone. Add sprint planning (2 hours), daily standups (2.5 hours), retrospectives (1 hour), and the manager's own leadership meetings (3-5 hours), and the calendar is 60-70% meetings before any actual work begins.

The remaining 30-40% of time is not "strategic work time." It is the time between meetings — 30-minute gaps that are too short for deep thinking and too long to waste. The manager fills them with Slack, email, and PR approvals. The strategic work — architecture decisions, process improvements, hiring plans, technical debt prioritization — never gets scheduled because there is no block large enough.

Code review becomes a bottleneck

Many engineering managers still participate in code review. At 10 direct reports producing 3-5 PRs per week each, that is 30-50 PRs the manager should review. Reviewing a meaningful PR takes 15-45 minutes. Even cherry-picking the most important 10, that is 2.5-7.5 hours per week on code review.

When the manager cannot keep up, PRs sit in review for 2-3 days instead of hours. Developers context-switch to other work. The sprint slows. The team ships less. Nobody blames the manager's span of control. They blame the "slow PR review process" and add a tool to fix it (which creates more tool sprawl).

Context switching destroys management quality

An overloaded manager handles: the senior developer who wants a promotion path conversation, the junior developer who is struggling with the codebase, the client who is unhappy with last sprint's velocity, the VP who wants a headcount plan by Friday, and the production incident that just landed in the alert channel. All between 10 AM and noon.

Each of these requires a different mode of thinking. The promotion conversation requires empathy and long-term perspective. The struggling developer requires patience and teaching. The unhappy client requires diplomacy and data. The VP requires a spreadsheet. The production incident requires technical diagnosis.

Switching between these modes 10 times per day is exhausting. The manager's quality of attention declines with each switch. The promotion conversation gets cut short because the incident needs attention. The incident analysis is shallow because the VP's headcount request is overdue. Nothing gets the full attention it deserves.

What It Costs

An overloaded manager costs more than an additional manager salary. The costs are distributed across the team:

Engineer attrition. Engineers who do not get adequate 1:1 time, career development, or technical mentorship leave. 24% of developers are unhappy and the #2 reason is lack of growth opportunities. Replacement cost: $150K-$250K per departure. One departure that a better-resourced manager would have prevented pays for a year of management capacity.

Reduced velocity. Google's research shows 25-30% productivity difference between teams with good versus overloaded managers. For a 10-person team at $80K-$160K per engineer, that is $200K-$480K in annual productivity loss.

Technical debt accumulation. A manager who is too busy for architecture reviews lets suboptimal decisions ship. Over 12 months, the accumulated technical debt becomes a tax on every future sprint. The 45% project overrun rate is partly a manager capacity problem: nobody had time to catch the architectural issue in sprint 2 that caused the overrun in sprint 12.

Burnout. The manager burns out first. Then the team burns out because the burned-out manager cannot support them. The cascade is predictable and expensive.

How to Fix It

Reduce span of control

The research is clear: 5-7 direct reports is optimal. Above 9, quality declines measurably. If your engineering managers have 10-12 directs, you need more managers, not more efficient managers.

The math: promoting a senior engineer to tech lead and giving them 4-5 direct reports costs one senior IC salary. The productivity gain from unburdening the existing manager is worth 2-3 senior IC salaries. The investment pays for itself in one quarter.

Separate people management from technical leadership

The model where one person manages engineers and also makes architecture decisions breaks at scale. Split the roles: engineering managers handle people (1:1s, career development, hiring, performance), and tech leads handle technology (code review, architecture, technical standards, debt prioritization).

This is how we operate at EltexSoft. Our fractional CTO handles technical leadership. The client's internal manager (or our PM) handles coordination and people management. The CTO reviews architecture. The PM runs sprints. Neither is overloaded because neither is trying to do both jobs.

HeyTutor ran this way for 9 years. Our co-founder handled technical leadership. The founders handled business priorities. Nobody was a 12-report manager trying to also review PRs and also attend board meetings and also write the technical roadmap.

Augment, do not stretch

When the talent shortage prevents hiring a new manager, augmenting the team with a retained engineering team that brings its own technical leadership reduces the existing manager's load without requiring a new hire.

Snapwire had 30 engineers and needed to scale. Instead of hiring 10 engineers and adding a manager, they brought our team of 10 with our tech lead included. The existing managers did not gain 10 more directs. Our tech lead managed our engineers. The span of control stayed manageable for everyone.

The manager overload problem is a capacity problem. Solve it with capacity: more managers, split roles, or retained teams that bring their own leadership. Do not solve it with tools, processes, or exhortations to "work smarter." An overloaded manager is not failing because they are not smart enough. They are failing because the job is too big for one person.

Talk to us →

Last updated September 1, 2024

Older
35% of Developers Use 6-10 Tools Daily. The Debugging Tax Is Real. Newer
You Can't Measure Developer Productivity with a Single Number

Google Search I/O 2026: AI Mode hits 1B, ships mini-apps

Dennis Vorobyov — Mon, 15 Jun 2026 13:26:54 +0000

Liz Reid, VP of Search at Google, announced at I/O 2026 that AI Mode hit 1 billion monthly users in its first year, with queries doubling every quarter. Source: Google's announcement post. The headline narrative — that AI is replacing Search — turned out to be wrong. AI is what is growing it.

The product reveal that matters is not the user count. It is what Search now does with them.

Mini apps, generated on demand

Google brought Antigravity, their agentic coding platform, into Search. You can ask Search to build you a fitness tracker. It writes one. Pulls real-time data, the local weather, reviews, live maps — gives you a custom dashboard that persists across sessions. Not a one-shot answer. A returnable workspace. Generative UI for one-off questions (visualizing how a watch works) and persistent dashboards for ongoing tasks (wedding planning, home moves).

US-only this summer for AI Pro and Ultra subscribers. Free generative UI for individual queries rolls out globally the same window.

I have been writing backend code for two decades. The first reaction to apps generated on the fly is skepticism — that phrase has lied to me before. The second reaction, after reading the announcement carefully, is that this is the most interesting Search product change in a decade. Not because the generated apps will be good. They will not be, often. Because the existence of generated apps changes the math on what is worth shipping yourself.

What the SERP can fake now

Three product categories just got harder to justify as standalone apps:

Lightweight personal trackers. Habits, light fitness, simple budgets. If Search can spin up a workable version on demand, you need a 10x differentiator to charge for one.
Comparison and decision-support tools. Search already handled vs queries. Now it generates side-by-side live dashboards in the answer.
Personalized monitoring. Information agents — also announced today — do this natively. Alert me when this rental matches my criteria. Notify me when these sneakers drop. No app needed.

Three categories that got more defensible, not less:

Deep workflows. Search can ship a tracker. It cannot ship a CRM with role-based access control, audit trails, and provisioning.
Regulated software. Search-generated UI does not sign BAAs. Healthcare, finance, legal — the compliance overhead is the moat.
Proprietary systems of record. When the UI layer commoditizes, the data layer underneath gets more valuable, not less.

What breaks

Generative UI is impressive in demos. Production engineering is where it gets hard:

State persistence. Where does the wedding-planning dashboard actually live? On Google's infrastructure, presumably. What happens when your data is in someone's prompt history.
Source of truth. The generated tracker pulls live data. From where? With what update cadence? What happens when sources disagree.
Failure modes. A real app has error handling. A generated app has I am sorry, let me try again.
Integration. Real apps connect to Stripe, Calendly, Plaid, your existing systems. Mini-apps in Search do not. Yet.

These are not reasons to dismiss the announcement. They are the seams where products built by humans still win.

What I would change on a backend project this week

Design APIs for agent consumption, not just browsers. Predictable pagination, idempotent endpoints, structured responses, explicit rate limits. The next caller of your API is going to be an LLM, not a user.
Ship semantic HTML and structured data on everything. Same conclusion the marketing team reached for a different reason. For backend engineers it is: if Search is going to cite your product, it has to read your product first. Server-rendered, machine-readable, no critical content trapped in client-side hydration.
Audit your roadmap against what Search now does for free. If Search can ship the feature you are scoping in a query, the feature is not a moat. The moat is the system underneath.

The honest take

This is not AGI in the search box. It is Google taking an explicit position on what it wants to own: the entry point, the agentic layer, and now the lightweight app layer too. Everything above the data is in play.

Build the data. Ship the integrations. Make sure the system underneath the UI can survive when the UI gets generated by someone else.

Last updated May 20, 2026

Older
Only 3% of Companies Have Truly Transformed with AI

Hidden Costs of Software Outsourcing

Dennis Vorobyov — Sun, 14 Jun 2026 13:26:54 +0000

Deloitte's 2024 Global Outsourcing Survey found that actual outsourcing costs exceed initial quotes by 15-25% on average. When you add scope creep (20-40% premium per Deloitte's separate analysis), skill mismatch failures (59% failure rate), and the switching costs when an engagement fails, the true cost of outsourcing is 20% or more above the number on the contract.

I run an outsourcing company. I am telling you the industry overcharges relative to what it promises. Not because every vendor is dishonest. Because the pricing model hides costs that only surface after the contract is signed.

The Costs Nobody Quotes

Management overhead

Every outsourced team requires management from your side. Someone must write requirements, review deliverables, attend standups, provide feedback, unblock dependencies, and make product decisions. That someone is usually a product manager or engineering lead whose time costs $80-$150/hour internally.

If your internal PM spends 10 hours per week managing the outsourced team, that is $40,000-$75,000/year in management overhead that does not appear in the outsourcing contract. It appears in your payroll as "existing headcount" even though the work is entirely driven by the outsourcing engagement.

The cheaper the outsourced team, the more management they typically require. A $30/hour team that needs 15 hours/week of management costs more in total than a $60/hour team that needs 5 hours/week. The rate difference is an illusion. The total cost tells the truth.

At EltexSoft, our CTO as a service model is designed to minimize this overhead. Our co-founder or senior tech lead manages the engineering side. The client's product person focuses on business priorities, not engineering management. HeyTutor's non-technical founders did not manage our engineers. Our co-founder managed the engineering. The founders managed the business.

Communication tax

Distributed teams have a communication overhead that co-located teams do not. Every question that would be a 30-second desk conversation becomes a Slack message, a waiting period, and a written response. Multiply by 20 questions per day across a 5-person team and the communication tax is 2-3 hours of productive time lost daily.

Timezone differences amplify this. A team in India working 9 hours ahead of US Eastern creates a 24-hour feedback loop for any question that requires a synchronous answer. That means decisions that should take 1 hour take 2-3 days. Features that should ship in 1 sprint take 2.

Our team in Ukraine operates in European timezones with 5+ hours of US business day overlap. That overlap is not marketing language. It is the difference between same-day resolution and next-day resolution on blocking questions. Snapwire had 10 of our engineers integrated into a 30-person Canadian/California team. The timezone overlap meant our engineers attended the same standups, participated in the same code reviews, and resolved blockers in real time.

Knowledge transfer costs

When you start an outsourced engagement, the new team knows nothing about your product, your domain, your architecture, your conventions, or your users. The knowledge transfer period — where the outsourced team ramps up while producing minimal output — typically lasts 4-8 weeks.

During that period, your internal team spends significant time explaining context, reviewing code that misses the mark, and correcting misunderstandings. This is productive time lost from your internal team's output, and zero output from the outsourced team. The combined cost of 4-8 weeks of ramp-up can be $30,000-$80,000 depending on team size and rates.

This cost resets every time the outsourced team changes. If the vendor rotates engineers (common at large shops — the bait-and-switch problem), you pay the knowledge transfer cost again. And again. A vendor that rotates 30% of the team annually means you are permanently paying for ramp-up.

Our average engagement is 3+ years. HeyTutor: 9 years. MyFlyRight: 10 years. Greek House: 4 years. The knowledge transfer happened once. The team learned the domain, the codebase, and the business. They stayed. The ramp-up cost was paid once, not annually.

Rework and quality gaps

The cost that nobody talks about until it happens. The outsourced team delivers features that technically meet the spec but miss the intent. The code works but the architecture is wrong. The feature ships but the performance is unacceptable. The tests pass but the edge cases are not covered.

Rework rates on outsourced code vary widely by vendor quality, but industry estimates put it at 15-30% of initial development cost. That means a $100,000 deliverable may cost $115,000-$130,000 after rework. And the rework is often done by your internal team, not the outsourced team, because explaining the fix takes longer than just doing it.

This is the cost of the $30/hour rate. Not the invoice — the total cost including the rework your $150/hour internal engineer does to fix what the $30/hour contractor shipped.

Switching costs

When an outsourced engagement fails — and 59% fail from skill mismatch alone — the switching cost is enormous. Knowledge is lost. The vendor lock-in through knowledge loss means the new vendor starts from scratch. The ramp-up period resets. The management overhead spikes during transition. If the previous vendor's code quality was poor, the new vendor inherits technical debt they did not create.

Switching vendors typically costs 2-4 months of productivity loss and $50,000-$150,000 in direct costs. Most companies do not budget for this. When it happens, it is treated as an emergency, not an expected cost of the model.

The Total Cost Calculation

Take a typical outsourced engagement: 5 engineers at $50/hour for 12 months.

Quoted cost: 5 × $50 × 160 hours/month × 12 months = $480,000

Hidden costs:

Management overhead (10 hrs/week × $100/hr × 50 weeks): $50,000
Communication tax (estimated 15% productivity loss): $72,000
Knowledge transfer (6 weeks of reduced output): $40,000
Rework (15% of deliverable value): $72,000
Total hidden: $234,000

True cost: $714,000 — 49% above the quoted price.

Not every engagement hits all of these. Well-run engagements with stable, senior teams in overlapping timezones minimize most of them. But the $480,000 quote is never the true cost. The question is whether the hidden costs are $50,000 or $250,000.

How to Reduce Hidden Costs

Choose timezone overlap over lowest rate. The communication tax on a 12-hour timezone gap exceeds the savings from a $20/hour rate difference. European nearshore teams (Ukraine, Poland, Portugal) provide 5+ hours of US overlap at $50-$100/hour. The total cost is lower than a $30/hour team 9 hours away.

Demand team stability. The #1 predictor of hidden cost is team rotation. Every engineer swap resets knowledge transfer, increases rework, and taxes your internal team. Contractually require named engineers and advance notice of any changes.

Use retainer, not fixed-bid. Scope creep adds 20-40% to fixed-bid contracts through change orders. Retainer eliminates the change order overhead entirely.

Start with a trial sprint. A 2-4 week paid trial at $5,000-$15,000 reveals the true quality, communication style, and management overhead before you commit to 12 months. The cost of the trial is a rounding error compared to the cost of a failed engagement.

Measure total cost, not hourly rate. Track: total spend including internal management time, defect rate and rework hours, velocity relative to internal team, and time-to-resolution for blocking issues. These metrics tell you the true cost per delivered feature, which is the only number that matters.

Our $50-99/hour rate is not the cheapest. The total cost — including the management overhead we absorb through our CTO as a service model, the timezone overlap that eliminates communication delays, and the team stability that avoids knowledge transfer resets — is competitive with teams that quote $30/hour and cost $75/hour in reality.

Talk to us →

Last updated May 12, 2024

Older
48% of Augmented Teams Have High Attrition. Here's Why. Newer
Time Zones Kill Distributed Teams. Nearshore Fixes It.

Custom Software Development Cost in 2026

Dennis Vorobyov — Sun, 14 Jun 2026 01:26:53 +0000

Every agency website has a "custom software costs $50K-500K" page. That range is useless. Here's how to actually think about what your project will cost, from someone who's quoted hundreds of them.

Why cost ranges are meaningless

When someone asks "how much does custom software cost?" they want a number. What they get is "$50,000 to $500,000 depending on complexity." That's like answering "how much does a house cost?" with "between $100K and $10M."

The range is technically correct and practically useless. The real answer depends on three things: what you're building, who's building it, and how long you need them.

The three cost drivers

Team size and composition

Software is built by people. The cost is fundamentally a function of how many people work on your project and for how long.

A typical retained team for a mid-complexity product:

2-3 senior developers: $50-99/hr each
1 QA engineer: $40-70/hr
1 part-time tech lead or architect: $80-120/hr
1 part-time project manager: included in most studio rates

At EltexSoft's rates ($50-99/hr for seniors), a 4-person team costs roughly $35,000-60,000/month. That's $420,000-720,000/year.

For a smaller project — say, a single senior developer and a part-time QA — you're looking at $15,000-25,000/month, or $180,000-300,000/year.

Duration

Software projects take longer than you think. Every time. The most common mistake buyers make is underestimating duration by 2-3x.

A mobile app with a backend and admin panel: 4-8 months to launch, then ongoing maintenance and feature development.

A SaaS platform with user management, payments, and integrations: 6-12 months to launch, then continuous development.

A data pipeline or internal tool: 2-4 months, then periodic updates.

The "launch" is not the end. It's the beginning of the expensive part. Maintenance, bug fixes, performance optimization, new features, security patches, infrastructure scaling — this is where most of the lifetime cost lives.

Where you hire

Geography is the biggest cost lever. The same senior developer costs:

$150-250/hr in the US
$100-180/hr in Western Europe
$50-99/hr in Eastern Europe or Portugal (nearshore)
$25-50/hr in India or the Philippines (offshore)

A 4-person team for 12 months:

US: $1.2M-2M
Nearshore (Europe): $420K-720K
Offshore: $200K-400K

Nearshore gives you 60-70% of the offshore savings with significantly better communication, timezone overlap, and code quality. That's why we operate from Lisbon and Kyiv.

Real project costs from our experience

These are actual ranges based on projects we've built.

Mobile app (iOS + Android, native): $150K-400K for v1, plus $5K-15K/month maintenance. Our Unfold project (Apple Best of App Store) was a multi-year engagement with a dedicated team.

B2B SaaS platform: $200K-600K for v1, plus $10K-30K/month ongoing. Our HeyTutor marketplace has been an 8-year continuous engagement.

LegalTech claims portal: $300K-800K for the full platform including integrations with airlines, courts, and payment systems. Our MyFlyRight engagement has been running for 10 years.

E-commerce marketplace: $150K-500K for v1. Our Ripe project (B2B catering marketplace) was built from zero and later acquired by Hungry.

Internal tool or data pipeline: $50K-150K. Shorter engagements, smaller teams, well-defined scope.

The hidden costs nobody tells you about

Infrastructure. Hosting, CDN, monitoring, error tracking, email services, payment processing fees. Budget $500-5,000/month depending on scale.

Third-party services. APIs, authentication providers, analytics, search, file storage. These add up to $200-2,000/month.

Security and compliance. If you're in FinTech (PCI DSS), HealthTech (HIPAA), or handling EU user data (GDPR), compliance adds 15-25% to your development cost and requires ongoing investment.

Technical debt. If you build fast to hit a launch date, you'll accumulate shortcuts that slow you down later. Budget 15-20% of ongoing development time for refactoring and debt reduction.

Team ramp-up. New engineers need 2-4 weeks to become productive on your codebase. If your vendor has high turnover, you're paying this cost repeatedly.

How to budget realistically

For a startup (pre-revenue): Budget $15K-40K/month for a 2-3 person team. Plan for 6-12 months to launch. Total: $90K-480K to get to market. Keep a 3-month runway buffer beyond launch.

For a scaleup (revenue-generating): Budget $30K-80K/month for a 3-5 person team. This covers feature development, maintenance, and technical debt reduction. Annual: $360K-960K.

For an enterprise project: Budget $50K-150K/month for a larger team. Expect longer timelines due to compliance, integration complexity, and stakeholder management. Annual: $600K-1.8M.

Fixed-price vs. retainer

Fixed-price sounds safe but creates bad incentives. The vendor is incentivized to minimize scope and cut corners. You're incentivized to maximize features. Every change request becomes a negotiation. Most fixed-price projects end up costing more than retainer projects because of change orders.

Monthly retainer aligns incentives. You pay for a dedicated team. They work on your priorities. If priorities change, the team adapts. No change orders, no scope negotiations. You can scale up or down with 30 days notice.

We work on retainer exclusively. Our clients pay for a team, not a project. That's how you get engineers who stay for years and deeply understand your product.

What to do next

Define your product scope at a high level — not detailed requirements, just what the thing does
Estimate team size: 2-3 people for most products, 4-6 for complex platforms
Pick your geography and multiply: team size × rate × months
Add 30% buffer for unknowns
Talk to 3-5 studios and compare their estimates against your math

If you want to discuss your specific project, we're happy to give you a realistic estimate based on similar work we've done.

Last updated May 9, 2026

Older
Technical Debt Eats 40% of IT Budgets. Here's What to Do About It. Newer
The AI Skills Gap Is Real: What 2,015 Digital Leaders Actually Report