A McKinsey and University of Oxford study of large IT projects found the average one runs 45% over budget, 7% over schedule, and delivers 56% less value than promised — with one in six going so far off the rails it threatens the company's existence. Those numbers have been public for over a decade. The custom enterprise software development services industry has read them, absorbed them, and changed almost nothing about how it sells, staffs, and prices the work. That is the part worth being angry about.
The consensus take, and why it's a decoy
Ask the internet how to buy custom enterprise software and you get the same two-part liturgy every time. Part one: agonize over build versus buy. Part two: once you've decided to build, choose your vendor on the size of the firm, the breadth of the stack, and the maturity of the methodology — the certifications, the delivery framework, the case-study PDF with a happy logo on it. Score the vendors, weight the criteria, pick the highest number. This is presented as diligence. It is mostly theater.
Here is the thing the scorecard won't tell you: none of those criteria correlate with whether the software you get is any good three years from now. Big firms fail. Small firms fail. Firms with the deepest stack and the shiniest agile transformation deck fail. The build-versus-buy debate is real but it's a first-inning question; by the time you're evaluating custom enterprise software development services, you've already decided to build, and the industry keeps you re-litigating the easy question so you don't ask the hard one.
The hard question is who, and for how long
Enterprise software is not a deliverable. It's a living system that outlives the contract that created it — a payments flow wired to three legacy systems, a permissions model nobody fully documented, a scheduled job that fails silently every quarter for a reason known to exactly one person. The value of that system does not live in the repository. It lives in the heads of the people who built it. When those people leave, the value doesn't transfer with the code. It evaporates.
So the only question that actually predicts the outcome is a staffing question: will the same senior people who understand your system still be working on it in year two, year three, year five? Everything else — stack, size, methodology — is downstream of that. A mediocre framework maintained by people who remember why every decision was made beats a beautiful architecture handed off to strangers every eleven months. Continuity is the whole game, and the industry is structured to prevent it.
What 'services' actually means
Walk into the standard enterprise software services engagement and count the acronyms. You are buying staff augmentation, which in plain language means bodies on a bench, billed by the hour, assigned by availability rather than fit, and rotated off the moment a higher-margin account needs them. The large-consultancy version dresses this up with a pyramid: a senior architect sells the deal and appears at the steering committee, while the actual code is written by whoever's cheapest and greenest, churning through at the industry's normal rate — turnover north of 20% a year is unremarkable in this business.
That churn is not a bug in the model. It's the model. Body-shop economics reward utilization and rotation; the person who knows your codebase cold is a person who could be billed to a fresher, more profitable account. Every rotation resets the context to zero and calls the reset 'onboarding,' which you pay for. You are financing your own institutional amnesia, one handoff at a time, and the vendor books it as revenue.
The MVP factory is the same disease, smaller
At the startup end of the market the failure wears a hoodie instead of a suit, but it's the same organism. The MVP factory ships you a version one, collects, and moves to the next logo. Nobody who wrote your authentication layer will be reachable when it needs to scale, because they were never meant to stay. Enterprise buyers think this is a small-vendor problem. It isn't. The Fortune 500 gets the pinstriped edition of exactly the same throughput business, and pays ten times the rate for it.
What continuity looks like when a shop is built for it
I've run a boutique engineering studio for eleven years, and I'll tell you what we optimize for instead, because it's the whole thesis of this piece made concrete. Our engineer turnover runs under 5% a year against that 20%-plus industry norm. Of the 50-plus engineers we've hired since 2015, 15 have left voluntarily. Average engineer tenure is around eight years; average client engagement is around four. That is not an HR statistic to feel warm about. It is the single operational fact that determines whether the software we build survives contact with year three.
The proof isn't the retention number, it's what the retention number lets us do. We've been the engineering partner on one air-passenger-claims platform since 2016 — roughly a decade, same team — and the system we built from scratch on React, Laravel, and PostgreSQL has since processed over a million claims. We've been building and scaling a US education marketplace since 2016 too, running the hiring and the coding standards as it grew. You cannot fake that. You cannot rotate a bench through it. A ten-year partnership is either real or it's a slide, and most of this industry only has the slide.
Methodology is not the moat; discipline is
The other decoy is process. Vendors sell you ceremony — the framework, the ritual, the burndown chart — as if the arrangement of standups were what saves projects. It isn't. What saves an enterprise build is ruthless scope discipline: the willingness to cut the thing you don't need before it becomes the thing that sinks you. When we took on a stalled build that a prior team had failed to deliver, the fix wasn't a better methodology. It was a week of tearing the scope apart and re-estimating it something like ten times, cutting 30 to 50% each pass until we found the smallest thing that could actually ship. That is unglamorous, it doesn't fit on a capabilities slide, and it is worth more than every agile certification combined.
Continuity is what makes discipline possible, incidentally. A team that will still be here in three years cuts scope honestly, because they'll be the ones maintaining whatever they talk you into. A team that's rotating off next quarter has every incentive to say yes to everything and let the next person inherit the mess. This is also why we treat code review as non-negotiable — every pull request read by at least one other senior engineer before it merges. Not as a compliance checkbox, but because it's how context stays in more than one head, which is the only insurance against the day someone does leave.
The rate-card trap
Procurement loves a low hourly rate because it's the one number on the page that's easy to compare. It's also the number most likely to lie to you. A cheap hour attached to a high-churn bench is the most expensive software you can buy, because you pay it again every time you re-explain your own system to a new stranger. The honest way to price an enterprise engagement is by the total cost of the context over the life of the system — and by that measure, a slightly higher rate on a team that stays is a discount, not a premium. The industry prices by the hour precisely because pricing by continuity would expose most of it.
What to actually ask before you sign
Throw out most of the RFP. Ask the vendor its annual engineer turnover rate, and watch whether they know the number cold or have to 'get back to you.' Ask the average tenure of the engineers who will be on your account, by name, not the firm's headcount. Ask how long their longest current client relationship has run and whether it's the same team that started it. Ask who reviews the code and whether a second senior engineer sees every change. Those four answers tell you more about your five-year outcome than any stack diagram, any methodology, or any logo on the wall.
The position, stated plainly
Custom enterprise software development services are sold on the wrong axis. Size is not a proxy for quality, stack is not a proxy for judgment, and methodology is not a proxy for discipline. The one thing that predicts whether your system is an asset or a liability in year three is whether the people who understand it are still the people working on it. Buy the team that stays. Everything else on the scorecard is the industry keeping you busy so you don't ask the only question that matters.
Last updated July 24, 2026