You are paying for several off-the-shelf tools that each do most of what you need, none of them fit properly, and the monthly total has quietly become a real number. So the custom software question arrives: would it be cheaper to have something built that actually fits?
Usually not, and we say that as the people who would be paid to build it. Buying wins more often than software companies admit, because the comparison people run is the build cost against the subscription, and that is the wrong comparison. The right one includes what happens for the next five years, and it is the part that is invisible when you are annoyed with a tool.
Here is a framework that takes about an hour and is honest about both sides.
Why off-the-shelf software usually wins
Worth being concrete, because the argument for buying tends to be made lazily.
A product you buy has had thousands of hours of work by people who do nothing else, and thousands of customers finding the edge cases before you arrived. It handles the parts nobody thinks about until they bite: permissions, audit trails, exports, mobile, the tedium of tax and time zones. Someone else fixes it at three in the morning. It improves while you sleep, and none of that improvement appears on your invoice. And critically, if it turns out to be wrong you can leave in a month, having lost a subscription rather than a project.
The subscription is not the price of the software. It is the price of not owning any of that.
The five-factor score
Score each factor one to five for your own situation, then add them up. Be honest rather than flattering: everyone believes their process is unique, and most processes are not.
| Factor | Score 1 if | Score 5 if |
|---|---|---|
| How unusual is the process? | Others in your industry work broadly the same way, and products exist that are aimed at exactly this. | The way you do it is genuinely unlike anyone else, and you can explain precisely why in one sentence. |
| Is it your competitive edge? | It is admin. Necessary, invisible to customers, nobody chooses you because of it. | It is the reason customers choose you, and doing it differently is the business. |
| How much does it need to connect to? | It stands alone, or connects to one or two things that already have integrations. | It has to sit between several systems, including something old or in-house with no integrations at all. |
| How many people, how often? | A handful of people, occasionally. | Most of the company, all day, and small inefficiencies multiply into real money. |
| How fast does it change? | Settled. It worked the same way three years ago. | It changes constantly with regulation, customers or your own model, and you need to change it yourself. |
The second row carries more weight than the others. Building something that is not your competitive edge is the most common expensive mistake in this decision.
The hidden costs, both directions
| Buying | Building |
|---|---|
| Per-seat pricing that grows with the team, sometimes faster than the value does. | Maintenance forever. Dependencies age, platforms deprecate things, browsers change. Budget for it annually. |
| Features locked behind a higher tier you will eventually need. | Nobody else is finding your bugs. Every edge case is discovered by you, in production, usually on a Friday. |
| Configuration work, which is real work even though it is not development. | The person who built it leaves. If it is one head and no documentation, you have a serious problem in year two. |
| Your data lives in their shape, and getting it out later is a project. | Everything is your responsibility: security patches, backups, access control, none of it optional. |
| Working around the bits that do not fit, permanently, which is invisible but not free. | The unglamorous middle. Permissions, exports, error messages, mobile. Cheap to ignore in a quote and expensive to omit. |
| Price rises and acquisitions, which you cannot control. | It is never finished. There is no version where you stop paying attention to it. |
A rough rule from our own work: expect ongoing maintenance of roughly 15 to 25 per cent of the original build cost per year, just to stand still. Anyone quoting a build without mentioning that is quoting half the project.
Buy the commodity, build the edge
The answer most people should reach, and it dissolves the argument rather than winning it. You are almost never choosing between two whole systems. You are choosing per piece.
Accounting, payroll, email, storage, calendars, standard reporting: buy, without hesitation. These are solved, the products are excellent, and building any of them is a bad use of your money. Then build the one part that is genuinely yours: the way you price a job, the way you schedule around your particular constraints, the thing your competitors do worse.
Practically this often means a small internal tool that fills the gap between bought products and connects them, rather than a system that replaces them. That is a far smaller project, it fails cheaply if you are wrong, and it is most of what our internal tools work actually is. Where the gap is really about moving data between systems rather than a new interface, workflow automation is usually cheaper still.
When the tool is 80 per cent right
This is where most people actually are, and it is the moment the build conversation starts. Before it goes any further, the missing 20 per cent is worth taking apart, because it is rarely one thing.
| It looks like | It is often really | What to do |
|---|---|---|
| The tool cannot do X | It can, but not in the way you first tried, or it is behind a setting nobody found. | Half a day with someone who knows the product well. Cheaper than any other option on this page. |
| The tool will not fit our process | Your process grew around a previous tool and is not itself sacred. | Ask what it would cost to change the process. Sometimes the honest answer is nothing. |
| We need it to talk to our other system | A genuine integration gap, and the most common legitimate one. | A small piece of automation between the two, rather than replacing either. |
| The reporting is useless | The data is there and the reporting layer is poor. | Export to somewhere you can query. Far cheaper than rebuilding the system that holds it. |
| It does not handle our pricing | Usually real, and usually the genuine edge case worth building. | This is the one to build, and only this. |
Four of those five rows are answered without a build. That ratio matches what we see when people bring us a case they are certain requires custom software.
When people build and regret it
- Because the subscription felt expensive. Compare against five years of running the alternative, not against the licence.
- Because the tool was 80 per cent right. The missing 20 is often a configuration problem, or a process you could change. Try both before building.
- Because one influential person disliked it. Sometimes correct. Frequently it is unfamiliarity, and the same objection will arrive about the custom one.
- Because building sounded more interesting. Honest and human. It is not a business case.
- To replace something that works but is unfashionable. Ugly and reliable beats elegant and new for anything that runs your operations.
The question that settles most of these
If you take nothing else from the framework, take this one. Ask what happens to this software in five years if nobody champions it.
A bought product survives that question easily. The vendor keeps developing it whether or not anyone at your company is paying attention, and if it stops suiting you, you leave. A custom system does not survive it. It needs someone who cares that dependencies are current and that the thing still runs, and the honest history of internal software is that this person eventually moves on. What follows is a system nobody fully understands, that everyone depends on, and that nobody wants to touch. We are called in to take those over regularly, and it is always more expensive than the original build.
So the real question is not whether you can afford to build it. It is whether you can afford to keep it alive for as long as you need it. If the answer is a named person and a budget line, building is a reasonable decision. If the answer is that you will work it out later, buy something, because later arrives sooner than anyone expects.
Before you commit either way
- Write the process down, properly. Half the time this reveals that the problem is the process, and no software fixes that. It also makes you far better at evaluating products.
- Search the category properly. Not the two names you already know. There is often something aimed at exactly your industry that nobody in the room has heard of.
- Trial the closest one for a fortnight with real work, not a demo dataset. Note every workaround.
- Price both over five years, including the maintenance percentage above and including your own people's time.
- Ask what happens if you are wrong. Leaving a product costs a migration. Abandoning a build costs the build. That asymmetry should influence you more than it usually does.
Not for you if
The test we apply to our own quotes: if this were our money, would we build it? Ask any supplier that directly. The ones worth hiring have an answer, and sometimes it is no.