How to Turn a Business Idea into an MVP

The most expensive way to test an idea is to build all of it. Months go into features, the launch date slips, and only at the very end does anyone find out whether people actually want the thing.

A minimum viable product, or MVP, takes the opposite approach. It’s the smallest version of your product that real people can use, built to answer one question: is the riskiest thing you believe about this business actually true? It isn’t a cheap copy of the full product, a demo for investors or a prototype you plan to throw away. It’s real, working software with a deliberately narrow job. Below is the path we’d follow, using one made-up example throughout: an app where tenants report repairs and small landlords track them until they’re fixed.

Name the riskiest assumption

Every business idea rests on a stack of beliefs. For the repair app, they might include:

• Tenants will report repairs in an app rather than by text message or a phone call.
• Landlords lose real time or money to repairs that slip through the cracks.
• Landlords will pay a monthly fee to stop that happening.
• Local tradespeople will be willing to accept jobs through it.

Some could be wrong and the business would survive. Others would sink it. The riskiest assumption is the one that is both important (if it’s false, the idea falls over) and uncertain (you don’t yet have real evidence for it).

Ask of each belief: “What do I actually know, and how do I know it?” If the honest answer is “it seems obvious” or “my friends liked the idea”, that’s a guess, not evidence. Write the riskiest assumption down in one sentence. For our example it might be: “Small landlords will pay to have every repair tracked in one place.” Everything that follows is about testing that sentence as quickly and cheaply as you can. If you catch yourself designing features that don’t help test it, park them.

Talk to people, then pick one measure

Before you design anything, talk to the people you hope will use it. Not a survey: real conversations, one at a time, until you keep hearing the same stories.

How you ask matters more than how many people you ask. People are polite, and “Would you use an app that…?” almost always gets a yes that means nothing. Ask about what they have already done instead:

• “Tell me about the last time a repair went wrong. What happened?”
• “How do you keep track of repairs today?”
• “What have you tried to fix this? What did that cost you?”

Listen for workarounds. A landlord with a colour-coded spreadsheet and a folder of tenant messages has a real problem and is already spending effort on it. Someone who shrugs and calls it “a bit annoying” probably won’t pay you to solve it. The strongest signal is commitment: agreeing to a pilot, making an introduction, or paying a deposit. Compliments cost nothing. Commitments cost something, which is why they tell you more.

Choose one success measure

Next, decide how you’ll know whether the MVP worked, before you build anything: one measure, tied to the riskiest assumption, with a number written down in advance.

Good measures are about behaviour, not attention. Sign-ups and page views are easy to collect and easy to fool yourself with. What matters is whether people do the thing your business depends on: come back, complete the key task, pay. For the repair app, a measure might read: “Of the first twenty landlords we invite, at least four agree to pay when the trial ends.” The numbers are yours to set; what matters is that you set them first. Write down the result that would make you stop or rethink, too. Deciding that now, while you’re calm, stops you explaining away a weak result later.

Cut scope until it hurts

Now list every feature you’ve imagined. All of them. Then sort each one into a bucket:

Build the must list, and only the must list. Then check it again: first drafts tend to hide a few shoulds. Things that can usually wait:

• Admin screens. At first, a very simple internal page or a few scripts can do the job.
• Automated billing. Send your first customers an invoice by hand.
• Settings and preferences. Choose sensible defaults, then see what people actually ask to change.
• Every platform at once. A fast, mobile-friendly website may test the idea just as well as an app, for much less work.

Cutting scope can feel like making the product worse. It isn’t. Every extra feature is something to design, build, test and support, and it blurs the result: if the MVP works, you won’t know which part made the difference. Fewer features mean a faster build and a clearer answer. For more on how scope drives budget, see our guide to what custom software development costs.

Test before you write code

Sometimes the cheapest test needs no code at all. Before you commit to building the MVP, ask whether the riskiest assumption can be tested another way:

• A concierge test. Deliver the service by hand to a few customers. For the repair app, you could take repair reports through a shared inbox and chase them in a spreadsheet for five landlords, for a month. If they won’t pay for a person doing it, they are unlikely to pay for software doing it.
• A manual back end. Users see a simple form; a person quietly handles what happens next. It teaches you exactly what the automation will need to do.
• No-code tools. A form builder, a spreadsheet and an automation tool can stand in for a surprising amount of software for a few weeks.
• A clickable prototype. A Figma prototype lets people try the flow before it exists. It tests whether they understand the product, not whether they’ll pay for it.
• An honest landing page. Describe the product, say plainly that it isn’t ready yet, and ask for an email address or a pilot commitment. It tests whether the pitch lands.

These tests have limits. They don’t scale, and some assumptions can only be tested with real software. If your biggest risk is technical, such as whether an AI feature is accurate enough on your own data, the right first step is a small technical experiment, not a landing page. Our article on RAG vs fine-tuning covers one common version of that question. But when the risk is “will people want this?”, test that first, by whatever means is cheapest.

Build the smallest real version

When it’s time to build, design the smallest version that tests the assumption. That is usually one complete journey, end to end, done properly. For the repair app: a tenant reports a problem with a photo, the landlord is notified, and the landlord marks it fixed. One journey that works every time is worth more than five that half work.

Design before you build

Sketch the journey, turn it into a clickable prototype, and put it in front of a handful of the people you interviewed. Watch where they hesitate. A confusing screen takes an afternoon to fix in a design tool; the same problem found after launch can cost a whole sprint.

Build in short cycles

We build in two-week sprints with a working demo at the end of every one. Each demo is a chance to check the product against the riskiest assumption and to re-scope before the next sprint: drop what you’ve learnt isn’t needed, and pull forward what is. Long, silent build phases are where MVPs quietly turn into full products. With us, a focused MVP usually takes six to twelve weeks, after a short discovery to agree the scope.

Instrument it from the first release

If you can’t measure your success measure, the MVP can’t answer its question. Before launch, make sure the product records the handful of events that matter: an account created, a first repair reported, a repair marked fixed, and each time someone signs in or uses the product, so you can see who comes back the following week. Add error tracking too, so you hear about crashes from your tools rather than from your users. Collect only what you need, explain what you collect in your privacy policy, and follow the data protection rules where you operate.

What not to skimp on

“Minimum” applies to scope, not to quality. An MVP should be small, but it shouldn’t be fragile or careless. Three things are worth doing properly from the first day, because they are cheap to get right now and expensive to fix later.

Security basics

Real users mean real data, and a breach can end a young product before it has had a chance. At a minimum:

• Use a proven sign-in library or service rather than writing your own. If you store passwords yourself, store only salted hashes made with a slow algorithm built for passwords, never plain text, ordinary encryption or a fast general-purpose hash.
• Check permissions on the server, so one landlord can never see another landlord’s tenants.
• Keep passwords, keys and other secrets out of the code.
• Encrypt traffic, keep your dependencies up to date, and take backups you have actually tested restoring.

We work to OWASP guidance and security-review every product before it launches, MVPs included.

Data you’ll need later

The data from your first months is the record of what really happened, and you can’t go back and collect it afterwards. Use a proper database (PostgreSQL is a sound default), give every record a stable ID and a timestamp, and record who did what. Keep dates, amounts and addresses in clean, structured fields rather than free text. Done from the start, this costs very little extra. Added later, it is painful, and the history you didn’t record is gone for good.

A codebase you won’t throw away

If the MVP works, it becomes the foundation of the business, so build it like one. That doesn’t mean building for millions of users. It means a clear structure, automated tests on the core journey, CI/CD so every change is tested and released the same way, and infrastructure as code so the whole setup can be rebuilt from scratch. Clear structure, for most new products, means a well-structured monolith rather than many separate services; our article on monoliths vs microservices explains why.

Ownership matters here too. The code should live in your own repository from day one, and production should run in your own cloud accounts, so you’re never locked out of your own product.

Launch small, then decide

Resist the big launch. Release the MVP to a small group first: the people you interviewed, the ones who agreed to a pilot, a waiting list you can contact one by one. Keep it small enough that you can talk to every user and fix their problems quickly.

Watch two things side by side: your success measure, and what people tell you. Numbers show what happened; conversations explain why. When the two disagree, trust what people do over what they say. After the period you agreed, compare the result with the number you wrote down and make one of three decisions:

• Continue. The measure was met. Name the next riskiest assumption and start building from the should list.
• Change course. There’s some signal, but not enough. Find out why, change one significant thing (the audience, the price or the core feature) and test again.
• Stop. No real signal, even after changes. It’s a hard call, but stopping after a few months is a far better outcome than stopping after a few years.

Whichever you choose, the MVP has done its job. It has turned a guess into evidence.

Where to start

You can begin this week, without spending anything:

1. Write your idea in one sentence: who it’s for, and what changes for them.
2. List the beliefs it rests on, and circle the riskiest one.
3. Book conversations with people who have the problem, and ask about the last time it happened.
4. Write down one success measure, with a number, before anything is built.

When you’re ready to build, a short discovery is the natural next step. Ours is fixed-price, usually one to two weeks, and ends with a scoped plan and a real budget, so you know what the first version includes before any sprint begins. Our page on custom software development explains how we work, and if you’d like a second pair of eyes on your idea, you’re welcome to tell us about it.