What building software actually commits you to
The build side of the decision is nearly always costed as a project: a number, a timeline, a launch. That framing is what makes the decision look closer than it is.
Building creates obligations that do not end at launch and do not appear in the estimate. They are predictable, they are the same every time, and they are worth pricing before you commit rather than discovering in year two.
Working through them is the substance of a build vs buy analysis — the buy side has its own set, and comparing one list against nothing is how the wrong answer wins.
The five obligations
Security patching, indefinitely. Every dependency you pull in is a thing somebody else will find a vulnerability in. A bought product absorbs that; a built one hands it to you. This is not occasional work, it is a standing tax, and it is the obligation most often skipped in year one and paid for in year three.
Platform drift. The language, the runtime, the cloud services and the browser all move underneath you. Nobody asked for these changes and they arrive anyway. A system nobody touches for two years is not stable, it is accumulating a migration.
The bus factor. Somebody understands why it works. When they leave, that understanding leaves unless it was written down, and it is almost never written down at the level that matters — not what the code does, but why it does that instead of the obvious alternative.
Support. Your users now report bugs to you. There is no vendor to escalate to, no status page, and the person who fixes it is on your payroll.
The decision debt. Every choice that was correct at the time and is not any more. This is the biggest one and the hardest to see, because it presents as “development has got slower” rather than as a line item.
Why the estimate never includes them
Because they are not features and cannot be demonstrated. An estimate is built from a scope, a scope is built from what the system will do, and none of the five above is something the system does. They are things you do, forever, because the system exists.
A rough way to sanity-check a build quote: if it contains no ongoing figure at all, it is pricing the first release and calling it the system.
When the obligations are worth taking
They are worth it when the thing being built is why customers choose you. If the software encodes the judgement that differentiates the business, then the maintenance burden buys you something no vendor sells, and the obligations are the cost of owning your own edge.
They are also worth it when the alternative is worse. Four products glued together have all five obligations too — the glue needs patching, drifts, depends on one person’s understanding, and generates support load — with the added feature that nobody owns the seams. That comparison is often closer than it looks.
When they are not
If the process you are encoding is one that thousands of companies run the same way — payroll, ticketing, scheduling, accounting — you are proposing to take on five permanent obligations to replicate something a vendor already amortises across every customer. That case loses on arithmetic and it loses badly.
The test I use: could a competitor buy something that does roughly this, today? If yes, and you would still build, the reason had better be specific.
Making the obligations visible in a plan
The practical fix is not a better estimate. It is a budget with two lines instead of one.
The first line is the build: scope, timeline, launch. The second is the standing cost of the system existing — patching, upgrades, support, and the engineering time that goes to keeping it working rather than making it better.
Even a rough second line changes the conversation, because it makes the comparison against buying an honest one. A build quoted at one number against a subscription quoted per year is comparing a one-off to a recurring cost, and the build always wins that comparison because the recurring half was left out.
Track it afterwards as a proportion of engineering time. That figure is the one number here worth having, and it is specific to your system rather than borrowed from an article.
The number I cannot give you
I do not have a reliable multiplier for what these obligations cost as a proportion of the build. It varies enormously with dependency count, regulatory exposure, and how disciplined the original build was, and any single figure would be invented. What I can say is that treating it as zero is always wrong, and that a plan with no line for it is a forecast of a rewrite.
Related reading: buying software covers the obligations on the other side, which are real and different rather than absent. Buy and extend covers the hybrid most companies actually end up in. And when off-the-shelf fights your process covers the specific failure that pushes people to build in the first place.