When to build software, and when the honest answer is don't

Someone describes a process, explains why no product handles it, and asks what it would cost to build.

Perhaps a quarter of the time the answer is a real project. The rest of the time the honest answer is that three products already do this, and the reason none of them seemed to fit is worth examining before anyone writes code.

Four questions

1. Has anyone actually tried to configure an existing product to fit?

Not “looked at”. Configured. Most software is far more flexible than a trial suggests, and most evaluations stop at the first thing that does not work out of the box.

A surprising number of “we need custom software” conversations end with someone spending two days properly setting up a tool the business already pays for.

2. Is the process genuinely unusual, or just unusual to you?

Every business feels like its way of working is specific. Often it is specific in the details and entirely ordinary in structure — a pipeline, a checklist, a recurring schedule, an approval step.

If the structure is ordinary, off-the-shelf software will fit once the vocabulary is mapped. If the structure itself is unusual, and it is why customers choose you, that is a real case for building.

3. Can you afford the second year?

This is the question that gets skipped. Custom software is not a purchase, it is a dependency. It needs:

• Hosting
• Security updates
• Fixes when a browser or platform changes underneath it
• Changes as the business changes
• Somebody who understands it

A reasonable planning assumption is 15 to 20 percent of the build cost every year, indefinitely. If that number is uncomfortable, the build is unaffordable regardless of what the build itself costs.

4. What happens if it stops being maintained?

Off-the-shelf software has a vendor with an incentive to keep it working. Custom software has you. If the person who built it becomes unavailable, what happens?

There are good answers — documentation, common technologies, code you own outright, a maintenance arrangement. But there has to be an answer before you start, not after.

When building genuinely is right

It happens. The pattern is usually:

• The process is a real competitive advantage, not just a preference
• Existing tools have been properly evaluated, not glanced at
• The volume is high enough that the inefficiency actually costs money
• The business can fund it ongoing, not just build it
• It is narrow — one workflow done well, not a system that does everything

That last point matters more than the others. Successful small-business custom software is almost always small. The failures are the ones that tried to replace five products at once.

The cheap way to find out

Before committing to a build, a short piece of discovery answers the question far more cheaply than the build does:

• Map what actually happens now, including the exceptions
• Check properly whether an existing product fits
• If not, build a prototype of the smallest useful version
• Estimate build and ongoing cost honestly
• Make a build or do-not-build recommendation

We do this as a bounded piece of work, and “do not build” is a perfectly good outcome. It is a cheap answer to an expensive question, and we would rather deliver it than take on a project we think is a mistake.

The uncomfortable version

Most custom software commissioned by small businesses is not in use two years later. Not because it was built badly — often it worked — but because the business changed, nobody updated it, and drifting back to spreadsheets was easier than commissioning changes.

Building is not the risky part. Maintaining is. Anyone proposing a build who has not talked to you about year two is selling you the enjoyable half of the problem.