PRODUCT · 7 MIN READ
How to know if your business needs custom software
Custom software makes sense when a critical process no longer fits in a spreadsheet, a generic tool or a chain of manual tasks. The question is not whether you want your own application — it is whether the cost of not having one already shows up in your numbers.
The five signals that you have outgrown your tools
You do not need all of them. Two or three usually make it worth sitting down and running the numbers.
- The same data gets copied by hand between systems. Somebody exports from one tool and imports into another every week. It is the clearest symptom and the easiest to quantify: hours per month multiplied by the cost of that hour.
- The process lives in one person's head. If that person goes on holiday, the process slows down or stops. That is not a staffing problem, it is a systems problem.
- Work grows in proportion to volume. If serving twice as many clients means hiring twice as many people to do the same thing, part of that process should be automated.
- You pay licences for features you never use and still lack the one you need. That is the sign that the generic tool is simultaneously oversized and too small.
- Your edge is in the process itself. If you do something better than your competitors because of how you organise it, a standard tool forces you to work like everyone else. That is where owning the software becomes an advantage rather than an expense.
The three cases where the answer is “no”
We prefer to say this before starting. These are the scenarios where building custom usually goes badly:
- The process is still changing every month. Coding an unstable process fixes in software something that will be different tomorrow. Stabilise first, automate second.
- A standard tool already covers 90%. That remaining 10% almost never justifies building and maintaining an entire system. A small integration on top of what already works usually wins.
- Nobody on the team can give the project time. Custom software is built from the knowledge of the people doing the work. Without that availability, the result is an application that does not match reality.
HOW TO DECIDE IN ONE AFTERNOON
Count the hours per month lost to the manual process, multiply by the cost of that hour, and compare it against the cost of building and maintaining the alternative for two years. If it is not clearly in favour, it is not time yet.
Custom, off-the-shelf or integration: how to choose
| Situation | Best option | Why |
|---|---|---|
| Process common to the whole industry | Standard tool | Someone already solved it better and cheaper than you can |
| Two good tools that don't talk to each other | Integration | Low cost and keeps what already works |
| A proprietary process that differentiates you | Custom software | Exact fit turns into competitive advantage |
| A one-off, narrowly scoped need | Lightweight automation | Solves 80% for a fraction of the effort |
| Requirements still unclear | Wait and document | Building on unstable requirements multiplies cost |
Start with the smallest version that already creates value
The most expensive mistake is not picking the wrong technology — it is starting too big. A first version should be specific, not complete.
- Define the problem and the measurable outcome before choosing features. “Cut quote preparation from three days to two hours” is a goal. “Have our own CRM” is not.
- Pick a single complete flow, end to end. Better that one part of the process works perfectly than the whole process works halfway.
- Get it in front of real users early. Two weeks of real use teach more than two months of requirements meetings.
- Integrate where it creates the most value, not everywhere. There are usually one or two connections that remove most of the manual work. Start with those.
- Build a secure, maintainable base. Authentication, permissions, backups and audit trails from day one. Adding them later always costs more.
A tailored solution does not have to start large. It has to start specific: useful for today's real work and ready to grow when the business asks for it.
What to ask whoever is going to build it
- Who owns the code and who holds the accounts when we finish?
- What happens if in a year I want to change team?
- What is the estimated annual maintenance cost, separate from development?
- What part of the scope can be postponed without breaking the first version?
- What technology will you use, and how many people know how to maintain it?
If any of these questions makes your supplier uncomfortable, you already have useful information.