Three weeks is enough to build something real and put it in front of real people. It isn’t enough to build everything on your wish list, and it shouldn’t try to be. A short MVP is useful for one reason: it answers a specific question. If you’re not sure what that question is, the three weeks won’t tell you much.
What three weeks can prove
People will actually use it. Interviews and mock-ups are helpful, but nothing beats watching someone use a working product. You see where they hesitate, what they skip, and whether they come back tomorrow.
The idea works end to end. Building it forces the awkward questions into the open. Can a booking really be completed? Can we really pull that data from the partner’s system? Can the team actually fulfil the orders that come in? Better to find out now than six months in.
Stakeholders get it. Investors, managers and partners react very differently to something they can tap through themselves. A working pilot is often what gets the full build approved.
What it can’t prove
It won’t prove the product works at scale. An MVP is built to learn fast, not to handle your eventual user numbers. That’s fine, as long as the foundations are solid enough to build on rather than throw away.
It won’t settle every feature debate either. Most features are left out on purpose. The MVP tells you whether the core is worth building, not what goes in version three.
And it won’t give you a full business case. A three-week build plus a few weeks of pilot gives you early signals on retention and revenue. Treat them as signals, not proof.
How to scope it
Pick one user, one problem and one journey. For a booking app that might be “a customer finds a free slot and books it”. It shouldn’t be “customers, providers and admins can manage everything”.
Write down what you want to learn before anyone writes code. Something like “will small businesses book through the app instead of calling?” Then agree how you’ll know the answer.
Decide what stays manual. Plenty of good MVPs handle payments, onboarding or admin by hand behind the scenes. Users still get a real experience, and the build stays small.
Line up pilot users in advance. Twenty committed users you can actually talk to are worth more than a public launch nobody notices.
How the three weeks usually go
- Week 1: agree the core journey, design the key screens, settle the technical plan
- Week 2: build the essential features so they work end to end
- Week 3: test, launch to pilot users and agree what to measure
At the end you should have a working product, real usage, and a clear call to make: build the full product, change direction, or stop before you spend more. All three are good outcomes. The only bad one is spending a year building before you find out.
