Let us say the unpopular thing first: most of the time, you should buy. Off-the-shelf software is one of the best deals in business. Someone else spent years and millions building a tool for your exact problem, and you can rent it for the price of a few coffees a month. Building your own version of that would be reckless. So this is not a "custom is always better" argument. It is about a specific moment, the one where the tool you were smart to buy quietly turns into the thing holding you back.
Knowing the difference between those two states is most of the skill. Buy too little and you burn cash reinventing solved problems. Build too late and you pay a slow tax every single day. The goal is to notice the turn when it happens.
Why buying wins at the start
Early on, off-the-shelf software is almost always the right call, and for good reasons. It is cheap, because the cost is spread across thousands of other customers. It is fast, because it exists today and you can be running by the afternoon. And it is proven, because the obvious bugs were found and fixed by companies that hit them before you did.
When you are still figuring out how the business works, that combination is exactly what you want. You do not yet know your process well enough to build something around it, and paying to learn that lesson in code would be expensive. A subscription lets you try, switch, and change your mind cheaply. That flexibility is worth a lot when everything is still in motion.
The warning signs you have outgrown it
The problem is that businesses grow and tools mostly do not grow with them. At some point the fit starts to fray, and the signs are usually mundane rather than dramatic. You feel them before you name them. A few to watch for:
- Spreadsheets have quietly become the glue between tools that should talk to each other directly.
- The same piece of information gets keyed into three different systems by three different people.
- There are workarounds that everyone just accepts, the "oh, you have to do it this way" steps nobody questions anymore.
- You are paying for seats and features you never touch, because the plan that had the one thing you needed bundled in the rest.
- You cannot get the one report that would actually answer your question, only the ten reports the tool ships with.
- Your process has slowly bent itself to fit the software, rather than the software fitting your process.
Any one of these is survivable. The trouble is they rarely arrive alone, and they compound. Each workaround makes the next one feel normal, until the way you work is mostly shaped by the limits of tools you chose years ago for reasons that no longer apply.
The franken-stack problem
The most common version of this is what we call the franken-stack. It starts innocently. You buy a tool for sales, another for invoicing, another for support, another for scheduling, another for email. Each was a good decision on its own. But now there are eight subscriptions that all almost integrate. There is a Zapier connection holding two of them together, a nightly export bridging two more, and a person whose real job has become copying data between the rest.
None of these tools was designed to be the centre of your business, so none of them is. The centre ends up being the gaps between them, and those gaps are filled with human effort and fragile automations that break quietly and get noticed late.
The tools were never the problem. The space between the tools is where the cost lives, and nobody is subscribed to fix that.
How the true cost creeps up
When people compare build versus buy, they usually compare the subscription price against a build quote and stop there. But the subscription is only the visible part of the cost. There are three layers, and the two you cannot see on an invoice are usually the larger ones.
The first is subscription sprawl: the steady accumulation of monthly fees, half of them for capacity you do not use. The second is the manual glue work, the hours your team spends every week moving data by hand between systems that will not talk. That time is real money, it just does not arrive as a bill. The third is the quietest and often the worst: lost and inconsistent data. When the same customer exists slightly differently in three systems, you stop being able to trust your own numbers, and decisions made on shaky data cost more than any subscription.
When custom genuinely wins
Set against that, a custom build stops being a luxury and starts being the cheaper option once a few conditions are true. It is worth building when a process is genuinely your edge, the thing you do differently and better than competitors, because bending it to fit generic software throws away the advantage. It is worth building when your integration needs have outgrown what connectors can hold together. It is worth building when scale has made the manual glue work a full role rather than a nuisance. And it is worth building when you need a single unified view of the business, one place where the real numbers live, that no combination of separate tools can give you.
When several of those are true at once, the maths flips. The build is no longer competing against a cheap subscription. It is competing against the far larger, mostly invisible cost of holding a franken-stack together by hand.
The middle path that often wins
Here is the part most build-versus-buy conversations miss: it is rarely all or nothing. The best answer is usually not ripping everything out and rebuilding it from scratch. Your accounting tool is excellent at accounting. Your email platform is excellent at email. Replacing them would be its own kind of waste.
The higher-leverage move is often to build the glue, not the tools. Keep the off-the-shelf software you rely on, and build a custom layer over the top of it: a unified dashboard that pulls the real picture into one place, and automations that do the copying and reconciling your team does by hand today. You keep what works, remove the manual effort between the pieces, and get the single source of truth you were missing, without the cost and risk of replacing tools that are doing their job perfectly well.
A short decision framework
When you are weighing it up, four questions get you most of the way there. Fit: does the tool actually match how you work, or have you quietly reshaped yourself around it? Integration: does it talk cleanly to the rest of your stack, or is that a person's job? Cost trajectory: is the true cost, including the glue work, flat or climbing? And how core is it: is this a supporting function where generic is fine, or the process that is genuinely your edge?
Buy when the fit is good, the integration is clean, the cost is stable, and the process is not your differentiator. Build, or build the glue, when the answers start pointing the other way. The honest position is not "always buy" or "always build". It is knowing which one you are looking at right now, and being willing to change your answer as the business changes underneath it.