Idea to MVP in 14 Days: A Day-by-Day Plan

Fourteen days sounds like a marketing number. It is not, provided you are honest about what an MVP is: the smallest working product that can prove or disprove one important assumption with real people.

It is not a smaller version of the finished product. If you have not yet decided what that one assumption is, start with our earlier piece on what to build first. This one assumes you have, and is about the calendar.

Before day one: the one-sentence test

Write down, in one sentence, what someone will be able to do with this that they cannot do today. Then write down how you will know it worked.

A dental receptionist can see every overdue recall across the practice on one screen, and we will know it worked if they use it three days running without being asked.

If you cannot write both halves, you are not ready to start the clock. That is not a failure. It saves you two weeks of building the wrong thing.

Days 1 and 2: one user, one job, one number

Pick a single type of user. Not “small businesses”, but a named role with a named frustration. Speak to two or three of them if you possibly can, even for fifteen minutes each.

By the end of day two you should have:

The one job the product does
The one person it does it for
The one number that tells you whether it is working

Everything that does not serve those three goes on a list titled “later”. That list will be long. It is supposed to be.

Days 3 and 4: design the smallest path through it

Sketch the fewest screens that let that one person complete that one job from start to finish. Usually that is three to five screens, not fifteen.

Click through it as a rough prototype before writing code. This is the cheapest point in the whole fortnight to discover that a step is confusing or unnecessary, and you will discover at least one.

Days 5 to 10: build, and ship every day

This is the only stretch that is mostly engineering, and it has three rules.

Deploy on day five. Something live on a real URL, even if it does almost nothing. Getting the plumbing working early removes the most common way two-week plans slip, which is discovering on day twelve that the thing will not deploy.

Put a working version live every single day. Not a branch waiting for a big merge. Small, visible progress keeps scope honest, because anything you cannot finish in a day is usually a sign it belongs on the “later” list.

Use boring technology. A framework you know, managed hosting, an off-the-shelf login and payments provider if you need them. An MVP is the wrong place to try the interesting new thing. The goal is to learn about your customers, not your stack.

AI coding assistants genuinely compress this stretch. They are very good at the repetitive parts: forms, standard pages, data access, tests. They are much less good at deciding what the product should do, which is why days one to four matter as much as days five to ten.

Days 11 and 12: real people, real use

Put it in front of the people you spoke to on day one. Watch them use it if you can, rather than asking what they think.

What people say about a product and what they do with it are different kinds of evidence. You want the second kind. Note where they hesitate, where they give up, and what they try to do that the product does not support.

Day 13: fix what hurt

Not what you wish you had built. Only what stopped someone completing the one job. If three people stumbled at the same step, that step gets fixed. If one person wanted a feature, it goes on the list.

Day 14: decide

Look at your one number and choose one of three things:

Continue. The assumption held up. Build the next most important piece.
Change. People wanted something close to this but not this. Adjust and run another short cycle.
Stop. The assumption was wrong. That is a genuinely good outcome after two weeks, and a very expensive one after six months.

When 14 days is the wrong number

Two weeks is realistic for a web product doing one clear job for one kind of user. It is not realistic for everything, and pretending otherwise leads to rushed work in exactly the places it matters most.

Regulated data. Health records, payments you hold yourself, financial advice. Build the compliance in properly from the start. Allow for it.
Two-sided marketplaces. You need both sides at once, and the product is only half the problem.
Hardware, or anything that ships to an app store. Review cycles and physical parts run on their own schedules.
Replacing a system people already rely on. Migration and parallel running are the real work, and they are not a two-week job.

In those cases, the discipline still applies. One job, one user, one number, and ship something real early. The calendar is simply longer.

What to take from this

Most MVPs that take six months did not need six months of engineering. They needed a firmer decision on day one about what not to build. The fortnight works because it forces that decision early and makes every day’s progress visible.

If you are doing this on your own, our piece on how AI is making the one-person startup possible covers what you can realistically carry alone and when to bring someone in.

We build MVPs on this rhythm, usually on .NET and Azure, sometimes on whatever you already run. If you have an idea that has passed the one-sentence test, tell us about it and we will tell you honestly whether two weeks is the right number for it.