When custom software is the wrong answer
Most people who come to me asking for custom software would be better served buying something. I say that at the start because it is the single most useful thing I know about this category, and because saying it costs me work.
The reason is arithmetic rather than principle. Off-the-shelf software spreads its development cost across every customer. Custom software has exactly one customer paying the whole bill, plus the maintenance, plus the cost of the person who understands it leaving. To beat that, custom has to be doing something the market genuinely does not sell.
Sometimes it is. Working out whether you are in that case is what custom software development should start with, and it is a short conversation rather than a long one.
The three conditions
Building wins when at least one of these is clearly true. Not plausibly true — clearly.
One: the process is the differentiator. If how you do the thing is why customers choose you, encoding it in someone else’s product means encoding it in a shape they designed for your competitors. A logistics firm whose routing logic is its actual edge cannot buy that logic.
Two: the integration cost exceeds the build cost. This one is counter-intuitive and common. You can buy four products that each do a quarter of the job, and the glue between them turns out to cost more than the whole thing would have, while being less reliable and harder to reason about because nobody owns the seams.
Three: the data shape does not exist in the market. Most software is built around an assumed model of the world — customers, invoices, tickets. When your domain does not decompose that way, adopting a product means mangling your domain to fit its schema, and you will pay for that translation forever.
If none of those is clearly true, buy. If exactly one is true, buy and extend. If two or three are true, building is probably the cheaper path over five years.
The condition that is usually a mirage
“Nothing on the market does exactly what we want” is not one of the three. It is almost always true, and it is almost never sufficient.
The relevant question is not whether a product does exactly what you want. It is whether the gap between what it does and what you want costs more than building and maintaining the whole system yourself. Usually it does not. Usually the gap is a report you can generate elsewhere, or a workflow step you can absorb, or a preference that turns out to be negotiable once it has a price attached.
I have talked people out of builds on this basis, and the conversation is generally short: what does the gap cost you per month, and what would closing it cost to build and run. When those two numbers are on the same page the answer is usually obvious to both of us.
What custom actually buys you
When it is right, it is right for reasons worth naming precisely.
You get a system whose model matches your domain, so the awkward cases stop being awkward. You get to change it on your schedule rather than a vendor’s. You get to see inside it when it misbehaves. And you stop paying per-seat pricing for a shape that does not fit.
What you take on in exchange is real: you own the uptime, you own the upgrades, and you own the risk that the person who understands it becomes unavailable. That last one is the most common way custom software goes wrong, and it is a documentation and testing problem before it is a staffing problem.
Two things I will not claim
I will not tell you custom software is faster to deliver than buying. It generally is not, and anyone saying otherwise is comparing a build to a procurement process rather than to a product.
I will not tell you it is cheaper in year one. It usually is not. The case for building is a multi-year case, and if your planning horizon is shorter than that the case does not close.
Where the evidence lives
Everything on the lab page is my own work, running in your browser rather than shown as a screenshot — including a matching engine that withholds a recommendation when the evidence does not support one, which is the kind of behaviour that is straightforward to specify in a system you own and awkward to request from one you rent.
That is the honest version of the pitch. Not that custom is better, but that when the three conditions hold, it is the only way to get behaviour you can actually inspect.
Related reading: custom business software covers the smaller-scale version of this decision. Application development covers what the build itself involves. And if the buyer, the user and the security reviewer are three different people, enterprise software covers the work that adds — which frequently changes the arithmetic above, because that work is the same whether you build or buy.
The limit
This test is a filter, not a decision. It will tell you reliably when to buy. It will tell you when building is plausible, and then you still need someone to look at your actual data, your actual integrations, and your actual team before anyone commits money. A framework that claimed to settle it from a blog post would be selling something.