25 July 2026 · 3 min read

Building software when you are not a software company

Most founders who build an app build the wrong one first. Not the wrong idea, the wrong version of it, and the difference is recoverable if you catch it early.

Most founders who decide to build software do not fail on the idea. They fail on the version of it they build first.

The pattern is familiar. Someone has run a business long enough to see a gap nobody has filled. They can describe the problem precisely, because they have lived inside it for years. Then they sit down to build, and what comes out is not the thing that solves the problem. It is a general purpose platform that would solve the problem, along with nine others, for people who have never met them.

That is not a failure of ambition. It is what happens when you plan a build the way you would plan a business.

The instinct that causes it

Business planning rewards completeness. If you are raising money or hiring a team, the plan has to answer every question, because the questions are the point. Anything you have not thought about is a risk somebody will find.

Software does not work that way. Every feature you specify before you have a user is a guess, and guesses compound. The tenth feature assumes the ninth was right, which assumed the eighth was right, and by the time anyone touches it you have built a structure resting on a decision you made on a Tuesday for no reason you can now remember.

The useful discipline is almost the opposite of planning. Work out the smallest thing that would tell you whether you are right, and build only that.

What "smallest" actually means

It does not mean bad. A prototype that falls over the first time it is used tells you nothing, because nobody got far enough to have an opinion.

It means narrow. One user, one job, done properly.

• One kind of user. Not "businesses", but the specific person who has the problem and would notice if it went away.
• One job. The thing they currently do badly, slowly or not at all.
• Real conditions. Their data, their week, their patience level, not a demo.

You will want to add the second job almost immediately, because it is obvious and it is easy. Resist it until the first one is genuinely being used. The point of narrowness is not modesty. It is that when something does not work, you can tell which thing was wrong.

What to build yourself and what not to

The honest answer has changed. A founder with no engineering background can now get a working tool in front of someone in days, and that is a real shift rather than a marketing claim.

What has not changed is the second half. Getting something working and keeping something working are different jobs. The first rewards speed and tolerance for mess. The second rewards care about the parts nobody sees: what happens when two people do the same thing at once, what happens to the data when someone leaves, who can read what.

So the split we use is roughly this. Build the thing that proves the idea yourself, fast, and accept it will be thrown away. Get help before it holds anything you would be embarrassed to lose.

The test that matters

There is one question worth asking before any of this, and it is not whether the idea is good.

If this existed tomorrow, would anyone change what they do on Monday?

If the answer needs explaining, the answer is no. That is not fatal, and it does not mean the idea is dead. It means the version in your head is not yet the version worth building, and you have found that out before spending a year on it.

Which is the whole point.