From Idea to MVP: What to Build First

Most founders do not fail because they built badly. They fail because they built too much, too early, of the wrong thing — and ran out of money or patience before they found out what the right thing was.

The fix is to be ruthless about what gets built first. That single decision does more to determine the outcome than anything else in the project, and most people make it in one evening, in a notebook, based on what would feel satisfying to launch. This is how to make it deliberately instead.

What an MVP actually is

The term has been repeated into mush. Here is the useful definition:

An MVP is the smallest thing you can build that tests the assumption most likely to kill the business.

Every clause is load-bearing.

Smallest — every extra week of building is a week of learning nothing.

Tests — the point is to produce information, not a product. If you cannot say what you would learn from launching it, you are building on a hunch.

The assumption most likely to kill the business — not the second-most, not the one you find most interesting.

Notice what the definition does not say. It does not say "software", or "version one of the roadmap", or that it needs a login screen. An MVP is defined by the question it answers, not the shape it takes.

The misreading that costs the most money

The common misreading is that an MVP is the full product with the good parts removed — a cheap, stripped, slightly embarrassing edition of what you actually want to sell.

That framing produces a predictable disaster. You build eight months of software, half-finished in every direction, and launch something too thin to delight anyone that still took long enough to drain the budget. You learn one thing: people did not use the bad version. You do not learn whether they would have used the good one.

Here is the distinction that matters. A stripped-down product is the same object, worse. An MVP is a different object entirely, chosen because it answers a question quickly.

If you want to know whether restaurant owners will pay for a scheduling tool, the stripped-down approach builds a scheduling tool with three features instead of thirty. The MVP approach might be a spreadsheet you maintain for four restaurants by hand for six weeks, charging them $200 a month. The second is faster, cheaper, and produces a far better answer — including the answer to a question the software never would have raised, like whether the owner or the assistant manager is actually the buyer. It also has a property founders underrate: you can abandon it on a Tuesday without grieving.

Find your riskiest assumption

Before you can decide what to build, write down what you are assuming. Not a business plan — a list. Every idea rests on a stack of assumptions, and they usually fall into four groups:

1. Problem — this problem exists, and it hurts enough that people are already spending money or effort on it.
2. Solution — the thing I want to build actually solves it, in practice, not in theory.
3. Willingness to pay — people will hand over money for it, at a price that leaves a business behind.
4. Reach — I can find these people repeatedly and affordably.

Now make two passes over the list.

How confident are you, honestly? Score each from 1 to 5, harshly. "Contractors hate quoting" is probably a 5 — you have heard it from twenty people. "Contractors will pay $99 a month for software to fix it" might be a 2, and you are rounding it to a 4 because you want it to be true.

What happens if it is wrong? Some wrong assumptions cost you a feature. Others cost you the company.

Your riskiest assumption is the one with low confidence and high consequence. That is what your first build exists to test; everything else waits. This is uncomfortable, because it is usually the assumption you least want to look at. Founders build the parts they are confident about — which is why so many pre-revenue companies have a beautiful brand, a slick onboarding flow and no evidence anyone will pay. If that is where you are, validate the idea first before writing a line of code.

A worked example

Say you want to build an app that helps independent physiotherapists send exercise plans to patients.

• Problem: physios waste time assembling plans. Confidence 4. Wrong means the whole thing dies.
• Solution: an app fixes it. Confidence 3. Wrong means you rebuild.
• Willingness to pay: they pay $60 a month personally, rather than waiting for the clinic to buy it. Confidence 2. Wrong means the whole thing dies.
• Reach: you can get in front of them for less than the revenue they generate. Confidence 2. Wrong means a product with no way to sell it.

Payment and reach are both low-confidence and fatal. So the first build is not the app. It is something that puts a price in front of a physio and sees if a card comes out, and something that tests whether you can find fifty of them without spending $200 each.

The ladder of MVPs

There is a ladder of ways to test an idea, ordered from cheapest to most expensive. Climb it from the bottom. Most founders start three rungs too high.

The rungs are not mutually exclusive — twenty conversations, a landing page and five manually served customers make a complete validation programme, in six weeks for under $2,000. And the top rung is not the goal. Plenty of profitable businesses never build custom software. The ladder ends where your riskiest assumption is answered.

When each rung is appropriate

Conversations — always, first, no exceptions. Ten to twenty. If you cannot find twenty people to talk to about the problem, you have already learned that reach will be brutal.

Landing page — when you can describe the offer in one sentence and want to know if the pitch lands. Put a real price on it; a page with no price tests curiosity, which is worthless.

Pre-sale — when the product is deliverable in a defined timeframe and you can honestly say so. Take deposits, be explicit about the date, refund without argument if you miss it. The most reliable pre-build signal there is, and rare precisely because it can genuinely say no.

Manual delivery — when the value is a service or a result rather than the software itself. Which is more often than founders assume.

No-code — when you have served people manually, know the workflow cold, and manual delivery has become the bottleneck. The right rung for most first real builds.

Custom build — when a specific technical thing is genuinely the product, or no-code has hit its ceiling and paying customers are pushing against it.

Do the work by hand first

This is the recommendation founders resist hardest, and the one that saves the most money. For a large share of businesses, the correct first version is you, doing the work manually, for real customers, for money. Not a prototype, not a pilot — the actual service, delivered by hand with an inbox, a spreadsheet, a phone and your own hours.

Consider a business that monitors a contractor's online listings and fixes inconsistencies. The instinct is to build a platform: crawlers, a dashboard, alerts, a client login. Three months, real money.

The manual version: you check the listings yourself every Monday for five clients and email each a one-page summary. You charge $150 a month. Setup takes an afternoon. Within six weeks you know whether they read the report, whether they renew, which listings actually matter and what they ask for that you never anticipated. You will almost certainly find that half of what you planned to build was pointless, and that one thing you never considered is the reason people pay. That is worth more than three months of engineering, and you got paid to acquire it.

The objections come in three flavours, and each has a short answer.

"It does not scale." Correct, and not the point. It teaches you which parts are worth the cost of scaling. When manual delivery starts hurting, you have located the exact bottleneck worth automating — and you will automate the right thing, because you have done it a hundred times.

"Customers will know it is manual." Mostly they will not care, and when they notice, they often like it. Buyers of small-business services care about the result and the reliability. Nobody cancels because a human assembled the report.

"It feels like cheating." It is the opposite — the version where you cannot hide behind a build schedule, facing the customer every week with nothing to sell but the actual value.

One caveat: charge for it. Free manual delivery teaches you almost nothing, because people accept anything free. The price is the test. If nobody pays for the manual version, the automated one was never going to save it — automation cuts your cost, it does not create demand.

Scoping a first build that ships in weeks

Once you have earned the right to build something, the goal is to ship in weeks. Here is how to force that.

Start from the date, not the feature list. Pick six weeks, then ask what fits. This produces a smaller, sharper build than listing features and estimating, because a list always grows to fill the estimate.

Write the single core action. One sentence: "A customer books a slot and pays a deposit." "An owner uploads a photo and gets a quote back within an hour." Everything in the build either serves that sentence or gets cut.

Draw the one path through it. The narrowest route from arriving to getting value. No branches, no alternatives, no edge cases.

Make the edges manual. Refunds, cancellations, unusual requests, anything happening less than once a week — handle it by email. Automating a monthly event is a bad trade at this stage.

Decide what "good enough" means. Fast and reliable on the core path; plain everywhere else. A build can be simple without being sloppy, and customers forgive plain far more readily than broken.

Name the metric before you build. What number, at what level, by what date, would tell you this worked? Write it down where you cannot edit it later. Founders are unnervingly good at retroactively deciding that whatever happened was the goal.

If you would rather not run this alone, it is what a build order is for — the sequencing of what gets built first, what waits and what never gets built at all. That is the substance of how we scope engagements.

The features that almost always get built too early

Some things get built first by reflex, in almost every project, and are almost always wrong at this stage.

• User accounts and login. Registration, password resets, sessions, permissions — a large amount of work that adds friction before the customer has any reason to trust you. Many first versions work fine with a link, a code, or nothing at all.
• Dashboards. Founders love dashboards; customers glance at them once. Until people use the product regularly there is no data worth displaying and no habit that brings them back to look.
• Admin panels. You are the admin and there are twelve records. Edit the spreadsheet directly. Building an interface so you can serve yourself is the purest form of avoiding customers.
• Integrations. Every one is someone else's API, auth flow, rate limits and outages. Build it when a paying customer says specifically that its absence is why they are leaving.
• Mobile apps. Store review, two platforms, a release cycle measured in days. A mobile-friendly web page tests the same idea in a fraction of the time.
• Billing tiers. Take payment, absolutely. But a payment link and a manual invoice beat a subscription system with three tiers, proration and dunning when you have four customers.
• Settings and customisation. Every option is a decision deferred to the user and a doubled testing surface for you. Pick sensible defaults.

None of these are bad; a growing business eventually needs all of them. The mistake is always the timing, and always for the same reason: they are comfortable to build and require nobody to say yes to you.

Saying no to your own good ideas

Bad ideas are easy to reject. The hard cuts are your genuinely good ideas — the ones that would clearly make the product better, that you can defend articulately, and that will add five weeks. Three tools that work.

The parking lot. One document. Every idea goes in it with a date and a sentence, and nothing gets built from it during the first version. Most of the pain of cutting an idea is the fear of losing it, and a parking lot removes that fear. Review it after launch and a third of the entries will no longer interest you — the cheapest possible way to have not built them.

The one-in, one-out rule. After scope is set, nothing gets added unless something of equal size comes out. This turns "could we also..." from a free wish into a real trade, and most ideas quietly withdraw when they have to compete.

The customer-request threshold. No feature gets built until a set number of real, paying customers have asked for it unprompted. Two or three works early on, written down, with names. It is remarkable how many urgent features never reach two.

The threshold applies to features, not to something broken on the core path. If the main action is confusing or failing, that is not a feature request, it is the product not working. Fix it immediately.

How to know when it is done

An MVP is done when it can answer the question you built it to answer. Not when it feels finished — it never will — and not when it is impressive. Ship when all of these are true:

1. A real customer, unassisted, can complete the core action end to end.
2. You can tell whether they got value from it — through usage, payment, renewal or a direct conversation.
3. The core path is reliable. Not everything. The core path.
4. Nothing on screen is misleading or broken-looking enough to distort the test. A shabby product produces a false negative, and that is the one bad outcome worth an extra week to avoid.

That last point is where "minimum" gets misapplied. Minimum means fewer things, not worse things. One feature done properly tests cleanly. Six features half-working test nothing, because when people leave you will not know which of the six drove them off.

If you are staring at the launch button looking for one more thing to add, ask whether it would change the answer to your question. Usually it would not. Usually it is fear, and one more week of building is the most respectable way to postpone finding out.

What to do with what you learn

Launching is the start of the measurement, not the finish line. Within two to four weeks you should be able to state plainly which of four outcomes you got.

Clear yes. People used it, paid, came back and told someone. Build the next thing — but re-run the question first, because your riskiest assumption has changed. It is usually reach: you proved people want it, and now you have to find them repeatedly, which is covered in getting to your first customers.

Yes, but not like that. People valued something adjacent to what you built. The most common result, and the most valuable. Do not defend the original plan — rewrite the core action sentence around what they actually wanted and ship again in weeks.

Yes, but not at that price. Demand is real, the economics are not. That is a business model problem, and building more product will not fix it. Test a different structure — different buyer, packaging or frequency — before you touch the build. See choosing a business model.

No. Nobody cared. Painful, and cheap at this price — weeks and a few thousand dollars rather than a year and a house deposit. Write down what you learned about the market, because the second idea from someone who genuinely tested a first one is usually much better.

The failure mode is none of these four. It is refusing to pick one — carrying on building, telling yourself the signal is unclear, because a definite no feels worse than an ambiguous maybe. It is not. The maybe costs you another six months. Set the review date before you launch, put it in the calendar, and on that date say the outcome out loud.

The short version

• An MVP is the smallest thing that tests your riskiest assumption — not a cheap version of the real product. Different object, different job.
• Score your assumptions honestly and build to test the one that is both shaky and fatal. It is usually willingness to pay or cost of reach.
• Climb the ladder from the bottom: conversations, landing page, pre-sale, manual delivery, no-code, custom build. Stop as soon as the question is answered.
• Deliver it by hand first, for money. It costs almost nothing and frequently proves the software you planned was the wrong software.
• Scope from a date, not a feature list. One core action, one path through it, every other good idea in a parking lot until launch.
• Ship when a real customer can complete that action and you can tell whether they valued it. Then pick your outcome honestly, on a date set in advance.