Someone on your team has a spreadsheet that shadows a piece of software you already pay for. They export from the tool, fix what it got wrong, add the columns it does not have, and email it round. Nobody planned this. It grew because the software nearly fits, and nearly is not the same as fits.
Buy off-the-shelf by default. Building is worth considering when three things are all true at once: the process is genuinely specific to how you operate, you are paying for several tools to cover one workflow, and someone on staff has effectively become the glue between systems. If only one of those applies, the honest answer is almost always to keep buying.
The Honest Default Is Buy
It is worth saying plainly, from a company that builds custom software: most businesses asking whether to build should not build.
Off-the-shelf software is dramatically cheaper up front. Somebody else fixes the bugs, ships the features, handles the security patches and stays awake when the servers wobble. The vendor has watched thousands of companies use the product and has already solved problems you have not encountered yet.
When someone tells us their CRM is not quite right, the useful first question is rarely "what should we build?" It is "have you configured this one properly?" A surprising share of build requests are really configuration problems, integration problems, or training problems wearing a more exciting costume.
Four Signals You Have Genuinely Outgrown It
That said, the default is a default, not a rule. Four signals suggest the calculation has changed.
1. The workaround has become a person
Somebody's actual job is now moving data between systems, or maintaining the spreadsheet that corrects the software. That is a salaried, recurring cost you are already paying: it simply is not itemised anywhere.
2. You pay for three tools to do one job
One for the form, one for the approval, one for the record, and none of them talk to each other. The subscriptions add up, but the real cost is the seam between them, where things get lost.
3. The process is genuinely yours
Not "we do it slightly differently": every company thinks that. Genuinely yours: an approval that routes through a role no vendor models, a rule that comes from your industry or jurisdiction, a structure the platform simply has no concept of.
4. The vendor's roadmap is not yours
You have asked for the same thing for two years. It is not coming, because you are not the customer they are building for. That is a reasonable decision on their part and a real constraint on yours.
Any single item on this list has a cheaper fix than building. It is the combination, especially the first and third together, that changes the arithmetic.
What Building Actually Costs
The build is the cheap part. What people underestimate is everything after it.
- The build itself. Genuinely faster than it used to be. A focused internal system is now a matter of weeks rather than quarters, provided the scope stays disciplined.
- Maintenance. Dependencies age, browsers change, requirements shift. Budget for continuing attention, not a one-off project.
- The knowledge. The biggest risk in custom software is not that it breaks. It is that only one person understands it. Anything built for you should be built to be handed over.
- The features you now own. Every improvement is yours to specify and pay for. Nobody ships you anything for free.
Set against that: no per-seat pricing that scales with headcount, no vendor deciding your roadmap, and a system that fits the process instead of a process bent to fit the system.
Scope Is the Whole Game
Custom projects fail for one reason more than any other: they try to be a platform when they only needed to be a tool.
The discipline is deciding what you are deliberately not building. A task system that stops at a simple board (no sprints, no story points, no epics) is not a limitation, it is the reason it shipped. A reporting screen that answers the four questions people actually ask beats a report builder that answers any question badly.
The other half of the discipline is knowing where the rules should live. Business rules encoded in the interface can be bypassed by anything that talks to the database directly. Rules enforced in the database itself hold no matter what queries it, which matters for anything involving permissions, money or people's employment.
When we built a staff management system for a church recently, the scope discipline was the reason it took eleven days rather than several months: a deliberately simple task board, no self-reported hours, and every access rule pushed down into Postgres rather than bolted onto the interface.
A Decision You Can Make This Week
Work through it in this order and most cases resolve quickly.
- Write down the process: the real one, including the workaround. Most teams have never seen it written in one place, and a fair share of problems become obviously fixable at this step.
- Price the workaround. Hours per week times the salary of whoever does it, plus the subscriptions you are paying to make it work. That number is your budget, and it is usually larger than expected.
- Try to buy it one more time, now that you can describe exactly what you need. Ask a vendor to demonstrate your specific path, not a generic one.
- If nothing fits, build the smallest thing that removes the workaround. Not the platform. The tool.
If you get to step four and are still unsure, that uncertainty is itself information: the pain is probably not yet large enough to justify owning software.
Frequently Asked Questions
Sometimes, but not for the reason people expect. Custom software avoids per-seat pricing that scales with headcount, which matters at size. It also carries maintenance costs a subscription hides. The stronger argument for building is usually fit rather than price, removing a workaround that is quietly consuming someone’s week.
Far less than it used to, provided the scope is disciplined. A focused internal system covering a handful of workflows is realistically a matter of weeks. Projects that stretch into quarters are usually trying to become platforms rather than tools.
Not that it breaks: that only one person understands it. A system whose logic lives in a single head is a liability regardless of how well it works. Anything built for you should come with documented decisions, readable code and a handover, so that maintaining it never depends on one person being reachable.
Write the process down and take it back to your existing vendor, asking them to demonstrate your exact path rather than a generic one. A large share of build requests turn out to be configuration, integration or training issues. If the vendor’s answer involves a workaround, you have found a genuine gap.
