The standard answer is: buy the off-the-shelf tool. In most cases that is the right call, and I say it regularly in conversations where I could be selling a project instead. There is a point where the math flips, though, and it is almost always noticed too late.
Too late means: once the licence costs already hurt, three tools run side by side and someone still moves data by hand every morning. By then the effort of switching has grown, and everyone stays with what's there out of inertia.
What's missing from the buy calculation
The monthly price is the smallest line item. What comes on top appears in no price comparison.
- Price per seat. €39 sounds harmless. With twelve people that is €5,600 a year, every year, price increases included. And every new hire raises the bill before they have earned their first euro.
- The add-on modules. In my experience, the exact feature you need sits in the next tier up. That jump rarely costs ten percent, more often it doubles the price.
- Adapting it to your process. Either you bend your process to the tool or you pay for customisation. Both cost, just in different places, one in the quote and the other in daily friction.
- The integrations. If the tool doesn't talk to your other systems, you get exactly the copy-and-paste work you wanted to get rid of. Those hours appear on no software invoice, but they are real.
- Rolling it out. Migration, training and the weeks where everything runs slower. That is a one-off, but a real one, and it is due again with every change of provider.
- Getting out. Your data lives with someone else. How easily you get it back is decided when it is already too late: an export that only produces PDFs is not an export.
What's missing from the build calculation
The other side gets talked up just as much. Costing custom software at the development price alone leaves out half of it.
- Running and maintaining it. Hosting, updates, security patches. Not much money, but never zero.
- Changes. Your business changes, the software has to follow. That is not a flaw in the project but the normal case, and the line item to plan for permanently.
- The bus factor. Software only one person understands is a risk. Proper documentation and readable code aren't a luxury, they are the insurance against it.
- Your own time. With custom software you have to decide, test and give feedback. It is time well spent, but it is time, and it falls in exactly the weeks that are busy anyway.
- The things a standard tool brings along. User permissions, logs, backups, a forgot-password flow. None of it is exciting, all of it has to exist.
If you pay more than around €300 a month for off-the-shelf tools and still move data between them by hand, it's worth seriously costing out a custom build.
The three cases where building really pays off
Your process is your competitive advantage
If you do something differently from everyone else in your industry, no standard tool will represent it. It forces you into the process built for your competitors as well, and takes away exactly what customers come to you for.
Licence costs grow with the team
Per-seat pricing punishes growth. Custom software costs the same whether five or fifty people use it. Past a certain team size the ratio flips, and it stays flipped.
You need three tools for one process
As soon as several tools exist only because none of them is enough on its own, you pay three times and still do manual work in between. That is the most expensive state of all.
Standard software is the right choice for tasks everyone does the same way. Custom software pays off where you deliberately work differently.
A worked example with real numbers
Take a company of twelve. Two tools for the same process cost €480 a month together, so €5,760 a year. Because the two don't talk to each other, someone moves data for half an hour a day, which is 2.5 hours a week and 125 hours a year, at an internal rate of €60 that is €7,500. The status quo comes to around €13,000 a year.
A custom application for exactly this process costs, say, €14,000 once, plus €2,500 a year to run and change. In year one that is more expensive. From year two the process costs €2,500 instead of €13,000. The point where the decision has flipped sits at roughly 16 months.
The numbers are invented, the structure isn't. What's interesting is which side dominates: not the licence costs, but the manual work in between. Compare tariffs alone and you are comparing the smaller half.
Five questions for the provider before you sign
When the decision goes to the off-the-shelf tool, and it often does and rightly so, these five points decide whether you are still happy in two years.
- How do I get my data back out? Complete, machine-readable, at any time. Not on request and not as a PDF.
- What does the next seat cost, and what does it cost in three years? Price tiers and increase clauses are in the contract, not on the website.
- Is there an open interface? Without an API, every later connection stays manual work, and you pay for it in hours instead of euros.
- What happens on outage or acquisition? Small providers get bought, products get discontinued. The question isn't whether it happens, but what happens to your data when it does.
- How long am I committed? A one-year term is standard, three years is an argument for a discount and an argument against the flexibility you might need.
The third option that gets overlooked
The decision is rarely either-or. Often the best solution is a mix: standard tools for what is standard, meaning accounting, email and calendar, plus one small piece of custom software exactly where your process is distinctive. Add a few automations that connect everything.
That is usually far cheaper than a large custom build and far less annoying than five tools with someone moving data between them by hand. It also has a side effect: the custom part stays small enough to understand, to change and, if it comes to it, to replace.
“Custom software” in this context doesn't mean a system that does everything, by the way. It means one interface, one process, one user group. The projects that derail are almost always the ones where somebody tried to rebuild a standard tool.
How to do the math in ten minutes
Take the licence costs of every tool involved in the process, times twelve. Add the manual work that remains anyway, so hours per week times your internal hourly rate times 50. That sum is your annual status quo.
Compare it to the one-off development cost plus roughly 15 to 20 percent of it per year for running and changes. If the build pays for itself in under two years, the decision is usually clear. At three years or more, stick with the off-the-shelf tool.
Two additions to that calculation. First, count the errors manual work produces, meaning the mistyped number and the forgotten follow-up. Second, don't calculate with today's team, calculate with the one in two years. Both points move the result in the same direction almost every time.
And if you can't decide
Then automate first. A few connections between the tools you already have cost a fraction of a custom build and show within weeks where the process really jams. Whatever still gets in the way after that is a very precise specification, and much cheaper than guessing beforehand.
- The monthly price is the smallest line item. Seats, modules, integrations and manual work belong in the calculation.
- Custom software costs money after launch too: running it, changing it, documenting it.
- In practice the licence doesn't dominate the calculation, the manual work between the tools does.
- Building pays off for distinctive processes, growing teams and chains of tools.
- Payback under two years means build. Three years or more means buy.
- When in doubt, automate first, because it writes the specification for you along the way.
Common questions
Roughly what does custom software cost?
A clearly defined internal tool with one process, one user group and a clean interface usually lands in the low to mid four figures. Anything beyond that is a project you build in stages and reassess after each one.
Do I own the code in the end?
With me, yes, including documentation and access. Custom software that leaves you dependent on one provider is just another subscription, only without a price list.
Can I automate first and build later?
That is often the smartest route. Automation shows within a few weeks where the process really jams. Whatever still gets in the way after that is a very precise specification for the build, and much cheaper than guessing beforehand.
What about all the no-code builders?
For internal tools with manageable logic they are a serious option and often the fastest one. The limits show up with more complex rules, with many concurrent users and at export time. Here too, the question is how you get out again when the provider changes its pricing.
Who runs the software afterwards?
Technically it sits on a hosted server and updates itself for the most part. What remains is someone to call for changes and an eye on updates, usually a few hours a quarter and not a job of its own.
