Does Your Idea Actually Need Software?

I run a business that builds software, so this is an odd article for me to write. I write it because the question gets asked far too late, usually after the money has been spent.

A surprising number of the ideas I see described as software businesses are not, yet. Some of them never will be. And the ones that genuinely are would almost all benefit from a period of deliberately not building anything.

Start with what the customer is buying

The clarifying question is not “what should I build?” It is “what is the customer paying for?”

Sometimes the answer really is the software. They want a tool, they will log into it, and the value is in using it. Design software, accounting packages, project trackers.

But often the answer is an outcome, and software is simply one way of producing it. Someone paying for a tidier set of accounts does not care whether a machine or a person tidied them. Someone paying to find suitable candidates does not care whether the matching was an algorithm or you, at a desk, reading CVs.

If the customer is buying an outcome, you have a choice about how to deliver it — and in the first year, delivering it by hand is nearly always the better option. It is faster to start, costs a fraction as much, and teaches you what the software should eventually do.

Outcome: you separate the value you provide from the mechanism you use to provide it.

The manual version is not a compromise

Founders resist this because doing it by hand feels like not really having a business. It is worth pushing back on that firmly.

Several very large companies began with a founder doing manually what the software later did. It works because it collapses the risk. You find out whether people will pay before you build anything, you learn the process properly by living inside it, and every awkward edge case surfaces in week two rather than in month nine when it costs money to accommodate.

It has a cost, of course. It does not scale, and it is your time. But your time in year one is meant to be spent learning, and there is no faster way to learn than delivering the service yourself to ten paying customers.

The signal to build is when the manual version is working and demand exceeds what you can personally handle. At that point you know exactly what to automate, because you have been doing it. Building before that point means guessing at your own process.

Outcome: you build from a process you understand rather than one you imagined.

Things people build that they did not need to build

A few patterns come up repeatedly.

A marketplace with no supply. The build is not the hard part of a marketplace, and it is not what the founder should be spending on. Getting the first side onto the platform is the hard part, and you can do that with a spreadsheet and a series of emails. Build the software once you have the participants, not to attract them.

An app when a website would do. Mobile apps cost substantially more than a responsive website, require ongoing maintenance for two operating systems, and impose an installation step that most early users will not take. Unless you genuinely need the camera, offline use or push notifications, start on the web.

A platform when a service would do. “Platform” often means the founder is imagining many customers self-serving. Before that is realistic, you have a service business with a handful of clients, and a service business needs a way to deliver, not a way to self-serve.

Custom software that already exists. A surprising proportion of first builds recreate something you could buy. Existing tools, stitched together, will cover more early businesses than founders expect — and the version you assemble in a fortnight tells you what the custom version needs to do differently.

Outcome: you spend on the part that is genuinely yours.

When you should build

To be even-handed, there are clear cases where building early is right.

When the software is the product and there is no manual equivalent — the customer’s whole experience is using the thing. When the volume of transactions is high from day one and manual delivery would collapse immediately. When the value depends on something only software does well, like real-time processing or working across large amounts of data. When you are in a regulated environment and the controls and audit trail have to be in the system.

If you are in one of those, build. Build carefully and modestly, but build.

The uncomfortable question

There is one more, and it is the one I would most want a founder to sit with.

Is the reason you want to build software that the business needs it, or that building is the part you are looking forward to?

That is not a cynical question. Building is satisfying, it produces visible progress, and it is entirely within your control in a way that customers are not. It is also, for many founders, considerably more enjoyable than selling.

If you notice you are more excited about the build than about the customer, that is worth examining before you spend the money — because the business that results will be one you enjoy running only if there are customers, and getting those is the other job.