Build the smallest thing that proves people want it

A widely quoted CB Insights analysis of failed start-ups found that the most common reason was building something the market did not need. The minimum viable product exists to find that out cheaply. It is not a smaller version of your dream product. It is the smallest experiment that tells you whether the dream is worth building.

Start with one person and one moment

Good MVPs begin with a specific person in a specific situation. ‘Small businesses’ is not a customer. ‘A shop owner reconciling stock on a Sunday night’ is. When you can picture the moment, you can design the one action that makes it better.

Prove the pain before you build

Look for people who are already paying for a clumsy solution or working around the problem with spreadsheets and messages. Then ask for something that costs them: a deposit, a pre-order, a signed pilot. People are kind in interviews; they are honest with their money and their time.

When I coordinated the GaiaBloom MVP at Gaia Learning, research into UK schools’ needs for special educational needs support shaped who we approached first. The six pilot agreements that followed were the real validation; everything else was opinion.

Scope: subtract, then subtract again

List every feature you imagine. Cross out everything that is not essential to the one job. A first version should:

• focus on one or two essential features,
• be usable without training,
• deliver value the first time someone uses it, and
• be buildable in about four to eight weeks.

We delivered GaiaBloom in ten weeks, refining the experience with Figma prototypes and Hotjar data that showed where people hesitated, and keeping design, engineering and curriculum teams working from one shared plan.

Launch where early adopters already are

Do not post everywhere at once. Builders and early adopters gather in a few places: Reddit’s r/SideProject, Hacker News, Product Hunt (mid-week launches draw the most votes), Indie Hackers and smaller directories such as Uneed, where a new product is less likely to be buried. Pick two, write a post that explains the problem rather than the features, and reply to every comment.

Sell the job, not the technology

Customers do not buy AI, a database or a clever algorithm. They buy a job done: an invoice chased, a shift filled, a report written. Lead with the job and keep the technology in the background.

Let feedback lead, carefully

Launch, collect feedback, change one thing, relaunch. Watch behaviour as well as comments: which feature do people return to, where do they drop off, who comes back next week? The loudest request is not always the most valuable one. Retention, repeat use and willingness to pay are the signals that it is time to scale.