The often-cited McKinsey and Oxford study of large IT projects found them running, on average, 45 percent over budget while delivering 56 percent less value than the people who commissioned them were promised. That number has been quoted in every build-versus-buy deck for a decade, and it has changed nobody's behaviour, because everyone reads it the same comforting way: those were the other guys, the ones with bad vendors and worse luck. The pitch for custom business software survives it intact. You will hear that custom gives you exactly what you need, that it is a competitive advantage, that off-the-shelf tools never quite fit. All three are true often enough to keep the industry employed. All three are also how most companies talk themselves into building software they should have rented.
Here is the position, stated plainly so there is no doubt where this goes: custom business software is a liability before it is ever an asset. It becomes an asset only inside a narrow band — the part of your operation that is genuinely yours and genuinely worth defending. Everywhere outside that band, custom software is a maintenance obligation you have volunteered to carry forever, dressed up as ownership. The discipline that separates the two is not technical. It is the willingness to not build.
The story that sells the build
The conventional case for custom is built on three words: control, advantage, and fit. Control, because you own the code and answer to no vendor's roadmap. Advantage, because software shaped around your process supposedly beats software shaped around the average. Fit, because the demo of the off-the-shelf tool always has that one screen that does it backwards from how your team works. Each argument is individually reasonable. Stacked together they produce a conclusion that is usually wrong, because they smuggle in an assumption nobody examines: that the things you want to control, win on, and fit are actually special.
They mostly aren't. The screen that does it backwards is, nine times out of ten, your team doing something idiosyncratic for a reason nobody can name anymore. The 'advantage' is a login page, a permissions matrix, a billing flow, and a dashboard — the same four things every business builds, rebuilt at your expense. Control over commodity software is not an asset. It is a bill that arrives every month whether or not you opened the app.
The 80 percent you have no business writing
Strip a typical internal platform down to its parts and most of it is plumbing that thousands of companies have already solved and will keep solving better than you can afford to. Authentication. Role-based access. Notifications. Audit logs. Payments. Reporting. File storage. The CRUD screens that let someone create a record, edit it, and find it again. None of this differentiates you from a competitor, because your competitor has the identical list and is fighting the identical bugs. Writing it yourself buys you the privilege of patching it for the next ten years.
Payments is the cleanest example. There is a robust market — Stripe, Stripe Connect, PayPal, ACH rails — solving card handling, compliance surface, and edge cases that would cost you a team and a half to reach parity on, and you would still be behind. We integrate these for clients constantly, and the instinct that occasionally surfaces, to 'own the payment layer for flexibility,' is almost always a reflex toward control over something that should never have been a custom decision. The flexibility is imaginary. The maintenance is not.
The 20 percent that is actually worth it
Custom earns its keep in exactly one place: the workflow that is the business, the thing a generic tool literally cannot sell you because no generic tool models your edge. That is a real and valuable category. It is just much smaller than the build estimate implies.
A concrete case from our own work makes the line visible. We have been the engineering partner behind MyFlyRight since 2016, and the core of what we built from scratch is a claims-automation wizard for EU air-passenger compensation — the logic that turns a delayed flight into a filed, defensible claim. That engine is not plumbing. It is the company. No off-the-shelf product encodes that regulation, that decision tree, that workflow, because that workflow is the differentiator. The platform we built has since processed over a million claims, and the part worth owning was always the narrow, specific core — not the auth and the dashboards wrapped around it. That is the test: if a vendor could sell it to your competitor tomorrow, do not build it. If no vendor can, that is your 20 percent.
The failure is scope, not technology
When custom software projects die — and on the McKinsey-Oxford numbers a great many of them are dying slowly even when they ship — the post-mortem reaches for technical villains. The wrong framework, the junior team, the cloud bill. These are rarely the cause. The cause is that nobody had the authority or the nerve to cut scope, so the project grew a feature for every opinion in every meeting until it was too large to finish and too vague to test. Code did not kill it. The absence of subtraction did.
The most valuable week we ever spend on a project produces no code at all. On a stalled build we took over — a product the previous team had failed to deliver — we spent a week doing nothing but deconstructing scope, and re-estimated the thing roughly ten times, cutting 30 to 50 percent on each pass, until what was left was the smallest version that actually shipped. That is not a cost-saving exercise. That is the work. The hard part of custom software has never been making the computer do the thing; it is deciding, against every stakeholder's wishlist, which things are not worth making the computer do. A team that cannot say no is more dangerous to your budget than any technology choice.
The cost nobody puts in the quote
The build estimate is the part of custom software that is least likely to be the largest number. A long-standing rule of thumb in software engineering puts maintenance at well over half of a system's total lifecycle cost — the years after launch, not the months before it. That is the number that should govern the build-versus-buy decision, and it is the one that never makes it onto the slide, because it arrives after the project is celebrated and the original sponsors have moved on.
Put real figures on it. A custom marketplace or SaaS build lands, in our experience, somewhere in the range of 60,000 to 200,000 dollars depending on how much of that commodity 80 percent you insist on owning — and that is the down payment, not the price. Custom software is not a purchase; it is a marriage. The reason our average client engagement runs about four years is not loyalty, it is reality: the system you built last year needs the dependency upgraded, the integration rebuilt, the security patch applied, the feature that the regulator now requires. Buy a SaaS tool and that work is amortised across the vendor's entire customer base. Build it yourself and you are the entire customer base.
So when do you actually build?
The honest decision rule is short and it is not 'it depends.' Build the slice that is your competitive edge — the workflow no vendor can sell because it is the reason you exist. Buy everything else, and accept the off-the-shelf tool's eighty-percent fit as the cheapest eighty percent you will ever get. When you do build, build the smallest version that ships, put it in front of users, and grow it from evidence rather than from the launch wishlist. And price the decade, not the demo, because the demo is the only part that is cheap.
The pitch says custom business software gives you exactly what you need. The truer statement is that it gives you exactly what you specified, forever, including the parts you should never have specified at all. Used as a scalpel on your real differentiator, it is one of the highest-leverage investments a company can make. Used as a default — because a demo annoyed someone, because owning feels safer than renting — it is a liability with a launch party. Treat it as the liability first. Earn the asset second. Most software that gets built never makes that turn, and the ones that do are almost always the ones that were brave enough to build less.
Last updated July 22, 2026