When Should a Business Build Custom Software?

Assume you’ve already decided that a build might be justified. The next question is timing — and the answer is usually "later than you want to, but earlier than you’ll be forced to."

Six signals that the moment has arrived

1. A spreadsheet has become critical infrastructure. One workbook, several tabs, formulas nobody dares touch, and one person who understands it. When that file breaks, the business stops. That spreadsheet is a specification for software that should exist.

2. Growth costs headcount linearly. Every new client, product or location adds the same manual setup work. Businesses that scale profitably break that link; the usual way to break it is software.

3. Two systems disagree and nobody knows which is right. Someone spends a day a month reconciling. The reconciliation is the tell.

4. Your best people spend their day on admin. Skilled staff doing data entry is the most expensive automation you can buy.

5. Errors are normalised. "That happens sometimes" about something that costs money is a process problem with a technical solution.

6. You’re losing work because you’re slow. Quotes that take three days because assembling one is manual. Enquiries that go cold because nobody saw them.

Three signals it’s too early

• The process changes every month. Automating an unstable process bakes in decisions you haven’t made yet. Stabilise first.
• Nobody can describe the process end to end. If three people give three different accounts, you’re not ready to specify software — though mapping it is genuinely useful on its own.
• The real problem is organisational. Software doesn’t fix an unclear owner, a bad incentive, or two departments that don’t talk. It makes the dysfunction faster and more visible.

Start smaller than feels right

The most reliable failure mode in custom software is building version three before shipping version one.

A good first version:

• solves the single most painful part of the process, not the whole thing;
• is used by real people doing real work within weeks, not quarters;
• has an architecture that can grow, so v2 doesn’t require a rewrite;
• is honest about what stays manual for now.

You’ll learn more from four weeks of real usage than from four months of specification. Half of what you were certain about will turn out to be wrong — and finding that out early is the entire point.

What to have in place before you start

A named owner on your side. Someone who can make decisions without a committee. Projects without one drift.

An agreed definition of success. "Quote turnaround under two hours" or "no manual re-entry of orders". Something checkable.

A baseline. Measure the current process before you change it: time per case, cases per week, error rate. Without it, you can’t tell whether it worked, and you’ll be arguing about impressions in six months.

Access. To the systems, the data, and — most importantly — the people who actually do the work. Not their manager’s description of it.

An honest budget for year two. Software you use changes. If there’s no budget to improve it, it will decay into the thing everyone complains about.

What we do first

Our software projects start with a discovery phase, and it’s genuinely allowed to end with "don’t build this". Sometimes the answer is a configuration change, a process automation, or connecting two systems you already own.

That’s a smaller invoice for us and a better outcome for you — which is roughly the trade we’re trying to make consistently.

If you’ve got a process that’s costing you time, describe it to us. Even the conversation tends to be clarifying.