DEV Community: Dennis Vorobyov

AI Code Trust Crisis: Only 29% of Devs Trust It

Dennis Vorobyov — Wed, 01 Jul 2026 01:26:55 +0000

Stack Overflow's 2025 Developer Survey found that 84% of developers use AI coding tools. GitHub Copilot, ChatGPT, Claude, Cursor, and others. The adoption is near-universal.

The same survey found that only 29% trust the output.

That gap — 84% usage, 29% trust — is the most important number in software engineering right now. Developers are using tools they do not trust. They are generating code they review with suspicion. They are faster at producing text that might be wrong.

I run an engineering studio. Our engineers use AI tools. I use AI tools. The question is not whether to use them. The question is whether the productivity gains are real or illusory.

The Productivity Paradox

GitHub's claim: Developers using Copilot complete tasks 55% faster.

METR's finding (2025, peer-reviewed): Experienced open-source developers using AI tools were 19% slower on real-world tasks in their own repositories. Not faster. Slower.

How can both be true?

GitHub measured isolated coding tasks: "write a function that does X." These are exercises where the AI has seen millions of similar examples. The developer accepts the suggestion, maybe modifies it, and the task is done faster.

METR measured real work: fixing bugs, implementing features, and refactoring code in production open-source repositories. These tasks require understanding the existing codebase, navigating complex dependencies, respecting architectural patterns, and testing against real-world edge cases. The AI suggestions were plausible but often wrong in ways that required time to discover and correct.

The paradox: AI makes simple tasks faster and complex tasks slower. Most production engineering work is complex.

Where AI Tools Help

Based on what our team actually uses them for:

Boilerplate generation. Database migrations, CRUD endpoints, test scaffolds, configuration files. The code that follows a known pattern and has no domain-specific complexity. AI handles this well.

Documentation. Generating docstrings, README sections, and API documentation from existing code. AI reads the code and describes what it does. This saves time and produces reasonable first drafts.

Exploring unfamiliar APIs. "Show me how to use Stripe Connect for marketplace payment splitting" produces a useful starting point. Not production code, but a map of the API surface that accelerates the developer's understanding.

Refactoring patterns. "Convert this class component to a functional component with hooks" or "rewrite this callback chain as async/await." Mechanical transformations where the pattern is well-established.

Test generation. Given a function, generate unit tests covering the obvious cases. The developer still needs to add edge cases and domain-specific tests, but the scaffolding saves time.

Where AI Tools Hurt

Architecture decisions. AI suggests what it has seen most often in training data. That is not always (or even usually) the right architecture for your system. An AI will suggest a microservices architecture for a 3-person startup because that is what appears in most architecture blog posts. The right answer for a 3-person startup is a monolith.

Security-sensitive code. Authentication flows, encryption implementations, access control logic. AI suggestions frequently contain subtle security flaws: missing input validation, incorrect token handling, race conditions in authorization checks. These flaws are not obvious. They pass cursory review. They are exploitable in production.

Complex business logic. The matching algorithm for HeyTutor considers 100+ metrics. No AI tool can generate this from a prompt. It requires understanding the business, the users, the edge cases, and the failure modes. AI-generated code for complex business logic looks plausible and is almost always wrong in ways that only surface with real users.

Legacy codebase understanding. METR's finding makes sense here. AI tools do not understand why the code is the way it is. They suggest changes based on what "good code" looks like in general, without understanding the specific constraints, workarounds, and business decisions embedded in the legacy codebase. Following the AI suggestion introduces bugs because the suggestion ignores context the developer has not yet fed into the prompt.

How Our Team Uses AI

We use AI tools as drafting assistants, not as co-authors.

Every AI-generated code suggestion goes through the same code review process as human-written code. The reviewer is responsible for correctness, not the AI. If a developer submits a PR with AI-generated code that has a bug, the developer is accountable — not the tool.

We do not use AI for security-critical code. Authentication, encryption, and access control are written by senior engineers and reviewed by a second senior engineer. No AI in the loop.

We do not trust AI for architecture. Architecture decisions come from engineers who have built similar systems before. PropertyRate's Kohana-to-Laravel migration was designed by an engineer with 15 years of experience. No AI tool could have designed that migration plan because it required understanding the specific constraints of a 50-state appraisal management platform.

We do use AI for the productivity wins that are real: boilerplate, documentation, test scaffolding, and API exploration. These are genuine time savers that let our engineers focus on the hard problems.

The 29% Question

Why do only 29% of developers trust AI output? Because the other 71% have been burned. They accepted a suggestion that looked correct, shipped it, and discovered the bug in production. Or they spent 30 minutes debugging an AI suggestion that would have taken 10 minutes to write from scratch.

The trust deficit is not ignorance. It is experience.

The teams that use AI effectively are teams with strong code review practices, clear boundaries on where AI can and cannot be used, and senior engineers who can spot when the AI suggestion is subtly wrong. The teams that use AI poorly are teams that treat it as a replacement for engineering judgment.

84% adoption and 29% trust is not a contradiction. It is a realistic assessment of a tool that is useful within limits and dangerous beyond them. The engineers know this. The marketing departments of AI companies do not.

Talk to us →

Last updated August 3, 2025

Older
Time-to-Hire for Engineers Hits 95 Days Newer
Scope Creep Adds 20-40% to Outsourced Projects

AI Makes Teams Faster and Less Stable: DORA 2025

Dennis Vorobyov — Tue, 30 Jun 2026 01:26:55 +0000

Google's 2024 DORA (DevOps Research and Assessment) report, based on data from 39,000 professionals, found something nobody expected: teams using AI extensively in their software delivery process experienced higher deployment frequency but also higher change failure rates. They shipped faster and broke more things.

The 2024 DORA report classified teams into four clusters. The top cluster — "elite" performers — maintained both speed and stability. But a new cluster emerged that the researchers had not seen in 10 years of DORA surveys: teams that were fast but unstable. High deployment frequency, high change failure rate, slow recovery time. These were disproportionately teams using AI tools extensively.

I build AI products for clients and my engineers use AI coding tools daily. The DORA finding does not surprise me. I have seen the mechanism in practice.

The Data

DORA 2024 (n=39,000):

Teams using AI extensively in delivery had higher deployment frequency
Same teams had higher change failure rates (percentage of deployments that cause production incidents)
The "fast but unstable" cluster appeared for the first time in DORA's history
AI tool usage was the strongest correlating factor for this new cluster

The four DORA metrics that matter:

Deployment frequency (how often you ship)
Lead time for changes (commit to production)
Change failure rate (what percentage of deploys cause incidents)
Time to restore service (how fast you recover from failures)

Elite teams score well on all four. The new "fast but unstable" cluster scores well on #1 and #2 but poorly on #3 and #4. They ship fast. They break things. They take a long time to fix what they broke.

Why AI Makes Teams Faster AND Less Stable

Volume without understanding

AI coding tools generate code faster than humans type it. A developer using Copilot or Cursor can produce 3-5x more code per hour than one typing from scratch. But producing code is not the same as understanding code. When a developer writes a function themselves, they understand every line. When they accept an AI suggestion, they understand the intent but may miss subtle implementation details.

The METR study we covered in the AI trust paradox piece found that experienced developers using AI tools were 19% slower on complex tasks. The DORA data adds a new dimension: even when AI makes developers faster on simple tasks, the accumulated effect of not fully understanding the generated code shows up later as production failures.

A developer who generates 50 lines of AI-suggested code and reviews them for 2 minutes will catch obvious errors. They will miss: subtle race conditions, incorrect error handling in edge cases, security vulnerabilities in authentication flows, and performance issues that only manifest under load. These escape review, pass tests (because the tests were also AI-generated and test the happy path), and fail in production.

Test coverage illusion

AI tools are excellent at generating tests. Ask Copilot to "write tests for this function" and it produces a comprehensive-looking test suite in seconds. The problem: AI-generated tests tend to test the implementation, not the behavior. They test what the code does, not what the code should do.

When the code is wrong in a subtle way, the AI-generated test passes because it tests the actual behavior (which is wrong) rather than the expected behavior (which requires domain understanding to specify). The test suite shows 90% coverage. The change failure rate climbs. The team has a false sense of security.

This is not hypothetical. We have seen it on client codebases we inherited. A test suite with 85% coverage that does not catch the edge cases that cause production incidents. The coverage number looks great. The defect rate tells a different story.

Deployment velocity without deployment discipline

AI tools reduce the time from "idea" to "code in a PR." That is step 1 of 5 in a deployment pipeline. Steps 2-5 — code review, integration testing, staging verification, and monitored deployment — are not accelerated by AI. They are accelerated by discipline.

When step 1 gets 3-5x faster but steps 2-5 stay the same, the bottleneck shifts. PRs pile up in review. Staging becomes a queue. The team responds by shortening reviews ("it looks fine, the AI wrote it") and skipping staging ("it passed the tests"). Deployment frequency goes up. Change failure rate goes up. DORA captures exactly this pattern.

What Elite Teams Do Differently

The DORA elite cluster uses AI but maintains stability. How?

They review AI code like human code

Every AI-generated suggestion goes through the same code review process as human-written code. The reviewer's job is to verify correctness, not just formatting. This means the reviewer must understand the business logic, the edge cases, and the failure modes. If the reviewer accepts AI code without understanding it, they are not reviewing — they are rubber-stamping.

Our code review process does not differentiate between human-written and AI-suggested code. The reviewer is accountable for what merges. If AI-generated code causes a production incident, the reviewer missed it. This creates the incentive to actually review, not just approve.

They write tests before generating code

Test-driven development (TDD) is the antidote to the AI test coverage illusion. Write the test first, based on the business requirement. Then generate or write the code that makes the test pass. The test encodes the expected behavior, not the implementation. When the AI generates code that passes the human-written test, you have confidence. When the AI generates code and the test, you have nothing.

They maintain deployment discipline

Steps 2-5 do not get faster just because step 1 did. Code review takes the time it takes. Staging verification takes the time it takes. Monitored deployment (canary releases, feature flags, gradual rollout) takes the time it takes.

The teams that maintain stability resist the pressure to ship faster by cutting these steps. They use the time savings from AI-assisted coding to write more thorough tests, do more careful reviews, and deploy with more monitoring — not to squeeze more deployments into the same calendar week.

They monitor aggressively

When deployment frequency increases, monitoring must increase proportionally. More deploys means more opportunities for failure. Real-time error tracking (Sentry, Datadog), deployment-correlated metrics (error rate before and after each deploy), and automated rollback triggers are not optional at high deployment frequencies. They are the safety net that keeps fast from becoming unstable.

The EltexSoft Practice

We use AI tools. Our engineers use Copilot, Claude, and Cursor. We accept that these tools make certain tasks faster. We do not accept that faster means we can skip review, testing, or staging.

Our deployment practice on every client engagement:

CI/CD from day one (our co-founder sets this up before the first feature)
Code review required for every merge (no self-merges, no rubber stamps)
Automated test suites that run on every PR
Staging environment that mirrors production
Monitored deployments with rollback capability

Greek House went from releases every few months to same-day deploys. Not because we shipped recklessly fast. Because the CI/CD infrastructure, the test coverage, and the review process were solid enough to support daily deployment with confidence. HeyTutor has maintained this discipline for 9 years across thousands of deployments.

The DORA data confirms what we practice: speed without stability is worse than stability without speed. The goal is both. AI tools help with speed. Engineering discipline provides stability. Skip the discipline and you join the "fast but unstable" cluster. Maintain it and you stay elite.

Talk to us →

Last updated November 24, 2024

Older
Premature Microservices Are the New Technical Debt Newer
When Your Outsourced Team Leaves, the Knowledge Leaves Too

AI ROI Reality: 94% See No Meaningful Impact

Dennis Vorobyov — Sun, 28 Jun 2026 13:26:55 +0000

Everyone is using AI. Almost nobody is making money from it.

McKinsey's State of AI 2025 is the largest annual survey of AI adoption. 1,993 respondents across industries and geographies. The headline finding: only 109 firms — 5.64% — report that AI contributes meaningfully to their EBIT (earnings before interest and taxes). 61% report zero measurable financial impact.

I build AI products for clients. I have watched companies spend six figures on AI initiatives that produced nothing measurable. I have also watched companies spend $20,000 on a focused LLM integration that paid for itself in the first month. The difference is not the technology. It is the approach.

The Data

McKinsey State of AI 2025 (n=1,993):

5.64% report meaningful EBIT contribution from AI
61% report zero measurable financial impact
72% of organizations have adopted AI in at least one business function
The gap between adoption (72%) and value (5.64%) is the story

Boston Consulting Group (2024):

Only 26% of companies have moved AI pilots to production
74% are stuck in "pilot purgatory" — running experiments that never scale

Gartner (2025 forecast):

Through 2025, at least 30% of generative AI projects will be abandoned after proof of concept
The primary reason: inability to demonstrate business value

Three research firms. Same conclusion. AI adoption is widespread. AI value is not.

Why 94% Fail

They start with technology, not problems

The pattern I see repeatedly: a company buys an AI tool (or hires an AI team), runs a pilot, builds a demo, shows it to the board, and declares the pilot a success. Six months later, nobody is using it. The demo was impressive. The business value was zero.

The companies in the 5.64% do the opposite. They start with a specific business problem: "Our patient intake calls convert at 12%. How do we get to 20%?" Then they work backward: the AI implementation is the last decision, not the first.

RiseMD works this way. The problem was measurable: dental practices spending money on marketing with no visibility into which campaigns drove actual patient revenue. The AI layer (call grading, search positioning, attribution analytics) was built to solve that specific measurement problem. Result: $3.2M in production from $160K spend. 20X ROI. Not because the AI was sophisticated. Because the problem was specific and the success metric was defined before a line of code was written.

They build custom when they should integrate

Most companies do not need a custom-trained model. They need a commercial LLM (OpenAI, Anthropic, Google) integrated into their existing product with proper engineering around it.

Custom model training makes sense when you have proprietary data that no commercial model can access and when the performance improvement justifies the cost. For most business applications — document Q&A, content generation, data extraction, customer support — a well-engineered integration with a commercial model outperforms a custom model at a fraction of the cost.

The 94% who see no ROI often overspend on custom AI when an integration would have been faster, cheaper, and more effective.

They skip the engineering

A Jupyter notebook is not a product. A demo that works on 10 examples is not production software. The gap between "it works in the demo" and "it works reliably for 10,000 users per day" is where most AI projects die.

Production AI requires: error handling (what happens when the model returns garbage?), cost controls (what happens when a runaway loop burns through your API budget?), latency optimization (users will not wait 15 seconds for a response), monitoring (how do you know when quality degrades?), and fallback strategies (what happens when the API is down?).

These are software engineering problems, not AI problems. The companies that solve them are companies with strong engineering teams. The companies that fail are companies that treat AI as a separate initiative disconnected from their engineering organization.

They cannot measure success

"We implemented AI" is not a result. "AI reduced our customer support ticket volume by 34% and saved $180,000 per quarter" is a result.

The 5.64% who see EBIT impact measure AI the same way they measure any other business initiative: revenue generated, cost reduced, time saved, errors prevented. The 94% who see no impact often cannot tell you what they expected AI to achieve in the first place.

What the 5.64% Do Differently

Based on what I see across our client work and the McKinsey data:

They start small. One use case. One measurable outcome. Not "transform the business with AI." More like "automate the extraction of line items from invoices so the accounting team saves 12 hours per week."

They integrate, not build. Commercial LLMs via API, not custom models trained from scratch. RAG pipelines with their own data, not general-purpose chatbots.

They measure from day one. The success metric is defined before the project starts. Baseline measured. Target set. Progress tracked weekly.

They treat AI as engineering. The AI project runs in the same sprints, with the same code review process, the same CI/CD pipeline, and the same deployment standards as every other feature. It is not a separate "innovation lab" project.

They ship to production. 74% of companies are stuck in pilot mode (BCG). The 5.64% ship to production, get real user feedback, and iterate.

The EltexSoft Approach

We build AI as features inside larger products, not as standalone experiments. Every AI feature we ship has a defined business metric, a production deployment, monitoring, and cost controls.

Snapwire used ML-powered image tagging and quality scoring across millions of photos for Fortune 500 brands. The metric was matching quality: did the right photographer get matched to the right brand?

RiseMD uses AI for search positioning and call grading. The metric is patient revenue attribution: does the practice know which marketing dollar produced which patient?

Woodies Clothing uses AI for product recommendations and demand forecasting. The metric is conversion rate and inventory efficiency.

None of these started as "let's implement AI." All of them started as "here's a business problem" and AI was the tool that solved it.

If you are in the 94%, the fix is not more AI. It is better engineering around the AI you already have. Start with a problem. Define a metric. Build to production. Measure the result.

Talk to us →

Last updated January 18, 2026

Older
Staff Augmentation vs Outsourcing: An Honest Comparison from 11 Years of Running Both Newer
Outsourcing vs Outstaffing: A Plain-English Definition (and Why the Terms Confuse Everyone)

Shipping Gemini Nano on-device in a real app: the constraints nobody warns you about

Dennis Vorobyov — Sat, 27 Jun 2026 15:26:47 +0000

I shipped an Android app whose daily insight is written by Gemini Nano running entirely on the phone — no cloud, no prompt or output ever leaving the device. The integration looked trivial in the docs. The production reality had three hard edges that reshaped my architecture. This is the writeup I wish I'd had before I started.

Quick context: Tawen reads sleep, HRV, and activity from Health Connect, computes a readiness score (0–100) on-device, and then uses the ML Kit GenAI Prompt API (which sits on AICore, Android's system service for on-device foundation models) to explain that score in plain English. Health data, prompts, and outputs all stay on the device.

Here's what actually bit.

1. Inference is foreground-only, and it's enforced

My first design pre-generated the day's narrative in a WorkManager job so it'd be instant when the user opened the app. Clean, idiomatic, and completely wrong: the GenAI API returns ErrorCode.BACKGROUND_USE_BLOCKED the moment you call it without a visible UI — including from a foreground service. AICore deliberately refuses inference unless your app is the top foreground application.

This isn't a quota you can request around; it's a design constraint. So the architecture inverts: inference happens in front of the user, triggered by the screen that needs it, and everything that can be precomputed without the model (the score itself — more on that below) is precomputed, while the narration is generated live when a relevant screen is foreground. If you're planning to "warm up" an on-device LLM in the background, plan for it not to work.

2. AICore is effectively single-threaded — concurrency returns BUSY

The shared Gemini Nano model on the device is a single resource, and AICore serializes access to it. Fire two inference calls close together — say, two composables that each want a narrative — and the second comes back ErrorCode.BUSY. There's also PER_APP_BATTERY_USE_QUOTA_EXCEEDED for longer-horizon overuse.

The fix that made this stable was to stop letting UI call the model directly. Every Nano request goes through a single-owner inference queue: one coroutine owns the model, requests are serialized, each has a hard timeout, and callers await a result instead of racing for the resource. Treat the on-device model like a single serial device (because it is), not like a stateless cloud endpoint you can fan out to.

3. Different Nano versions give different output — so don't let the model own anything that must be stable

The docs note it plainly: different versions of Gemini Nano can return different output for the same prompt. For a narrative, that's fine — it's prose. But it means the model cannot be the source of truth for anything a user might compare day to day.

This drove the core architectural decision of the app: the score is deterministic; the model only narrates it. A plain rule-based engine computes the readiness score from five weighted signals. Gemini Nano writes the explanation about that score and never computes it. The benefits compound:

The number is identical whether Nano is available or not.
On devices without Nano (it needs recent hardware), a deterministic rule-based explanation takes its place and the score is unchanged.
"AI explains a transparent calculation" is a more honest and more debuggable shape than "AI emits a number you can't inspect." I label output as AI-written only when Nano actually wrote it. The rule-based fallback is never called "AI." That honesty turned out to matter more to users than the AI itself.

What I'd tell my past self

Read the error codes first, design second. BACKGROUND_USE_BLOCKED, BUSY, and the version-variance note are not edge cases — they're the shape of the platform. Designing around them up front would have saved me a rewrite.
Keep a deterministic core. Let the model do the soft, fuzzy, language part. Anything that needs to be stable, reproducible, or comparable should live in code you control. The fallback path you get for free is worth the discipline on its own.
On-device AI's real product win is privacy, not magic. The reason to do this isn't that Nano is smarter than a cloud model (it isn't). It's that a sentence about someone's sleep and heart-rate data can be generated without that data ever leaving their phone. Build around that and the architecture mostly designs itself.

If you're integrating ML Kit GenAI / Gemini Nano, I'm happy to compare notes — the foreground-only and single-owner-queue parts especially. The official docs are here; everything above is what they don't quite prepare you for.

AI Skills Gap 2026: Data from 2,015 Leaders

Dennis Vorobyov — Sat, 27 Jun 2026 01:26:55 +0000

Harvey Nash and Nash Squared have run the Digital Leadership Report for 26 years. The 2024 edition surveyed 2,015 digital leaders across 82 countries. One number stood out: 51% report an AI skills shortage in their organization. That is the steepest single-year rise in any technology skill gap since the report started in 1998.

I run a 35-50 person engineering studio. We build AI products for clients. I can tell you what this number actually means on the ground.

The Data

The Nash Squared report covers large enterprises and mid-market companies. The respondents are CIOs, CTOs, VPs of Engineering, Heads of Digital. These are not junior managers guessing about skills. They are the people responsible for hiring and delivery.

51% say they cannot find enough people with AI skills. That is up from roughly 35% the prior year. No other technology category — cloud, security, data engineering, DevOps — has ever jumped that fast in the report's history.

Gartner's 2025 CIO survey tells the same story from a different angle. 63% of CIOs say AI talent acquisition is a "significant challenge." Deloitte's State of AI in the Enterprise found that 68% of organizations are increasing AI investment but only 27% feel confident in their ability to execute.

Three surveys. Three methodologies. Same conclusion: most organizations want to build with AI but cannot staff the teams to do it.

Why the Gap Exists

The gap is not about people who can write a Python script that calls the OpenAI API. That takes an afternoon to learn. The gap is about people who can put AI into production.

Production AI means: choosing the right model for the task and the budget. Building retrieval pipelines that surface the right documents. Designing prompts that work reliably across thousands of inputs, not just the 10 examples in the demo. Setting up monitoring so you know when the model starts hallucinating. Implementing cost controls so a runaway loop does not generate a $40,000 API bill overnight. Deploying on HIPAA-eligible infrastructure when the client is in healthcare.

Those skills take years to develop. They require experience shipping software, not just experience with AI. The best AI engineers I have worked with are senior software engineers who added AI to their toolkit, not AI researchers who learned to code.

What This Means for Hiring

If you are trying to hire an AI engineer full-time in 2026, here is what the market looks like:

Senior AI/ML engineers in the US command $180,000-$280,000 in total compensation. Time-to-hire for senior engineering roles has hit 95 days on average. Offer acceptance rates are falling. The people you want are already employed and not actively looking.

In Europe, the numbers are lower but the competition is still fierce. Lisbon, Berlin, and Warsaw are all competing for the same talent pool. Remote work expanded the candidate pool in 2020-2022. By 2025-2026, it also expanded the number of companies competing for every candidate.

What Actually Works

Upskill existing engineers

Your senior Laravel or Django developer who has shipped production systems for 5 years can learn to integrate LLMs, build RAG pipelines, and deploy AI features faster than an AI researcher can learn software engineering. The production skills transfer. The AI-specific skills can be taught.

We have done this at EltexSoft. Our backend engineers who built Nautical Commerce (Django, 200K+ monthly transactions) and MyFlyRight (Laravel, 10 years) now build AI backends for RiseMD and other clients. The production discipline was already there. The AI layer was additive.

Partner instead of hiring

The 95-day time-to-hire for a full-time AI engineer assumes you find one. Many companies spend 6 months searching and hire nobody. Meanwhile the AI project sits idle.

A retained engineering team with AI experience starts work in 2-3 weeks. Not because we have a magic bench of AI specialists waiting. Because senior engineers who have already shipped AI products can ramp into your domain in days, not months.

Start with integration, not research

Most companies do not need a custom-trained model. They need an LLM integrated into their existing product with proper engineering around it: API design, error handling, cost controls, monitoring, and a fallback for when the model is down.

That is an integration project, not a research project. It requires the same skills as any other software integration — plus domain knowledge about prompt engineering, token management, and model selection.

The EltexSoft Perspective

We charge $50-99/hr for senior engineers who have shipped production AI. Compare that to a full-time US AI hire at $200K+ plus 6 months of searching.

The math: a 2-person AI team on retainer at our rates costs $16,000-$32,000/month. A full-time senior AI engineer in the US costs $15,000-$23,000/month in salary alone, plus benefits, plus the 3-6 months they were not working while you were searching.

The skills gap is real. The question is whether you close it by hiring into a tight market or by partnering with a team that already has the skills in production.

We build AI products, LLM integrations, RAG pipelines, and AI agents for clients across FinTech, HealthTech, and eCommerce. Production AI. Not demos.

Talk to us →

Last updated May 10, 2026

Older
How Much Does Custom Software Development Cost in 2026? Real Numbers, Not Ranges Newer
Only 3% of Companies Have Truly Transformed with AI

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