A one week MVP sounds like a gimmick. It isn't, as long as you are honest about what "minimum" means. Most products that take six months to launch did not need six months. They needed someone to say no more often. It is not a new idea either. GV's design sprint is built on the same principle: a five day process for answering critical business questions by designing, prototyping and testing ideas with real customers.
Here is how to scope a first version small enough to build in a week and still useful enough to learn from. It is the same scoping exercise we run at the start of every one week MVP engagement.
The six step scoping funnel
- 01
One problem
A real problem in one sentence.
- 02
One user
A specific role with a real need.
- 03
Shortest path
The fewest useful steps to the outcome.
- 04
Now or later
A strict cut between essential and optional.
- 05
Borrow tools
Build only what makes the product different.
- 06
Define the test
A clear signal to continue or change course.
Step 1: Write the problem in one sentence
Not the product. The problem. "Small clinics lose track of which patients missed follow ups." "Contractors spend hours chasing site photos over WhatsApp."
If you cannot write it in one sentence, you are not ready to build yet. Keep refining it until you can. Everything else in this process gets checked against that sentence.
Step 2: Pick one user
Not "clinics". The receptionist at a clinic. Not "contractors". The site supervisor. One person, with one job to get done.
Marketplaces and multi user platforms are the main reason MVPs balloon. If your idea needs two sides, ask whether you can fake one side by hand for the first few weeks. Often you can. A founder matching buyers and sellers over email is a perfectly good first version of a marketplace.
Step 3: Map the shortest path to value
Write down the steps your user takes from opening the product to getting the thing they came for. Then delete every step that is not strictly needed.
For the clinic example, that might be:
- Upload or type in a list of patients and visit dates.
- See who is overdue.
- Send them a reminder.
That is the product. Reports, dashboards, user roles and settings can all wait.
Step 4: Draw a hard line between "now" and "later"
The "later" list is not a rejection. It is your roadmap, and real users will tell you which items on it actually matter.
Step 5: Borrow everything you can
In a one week build, you should be writing code only for the part that makes your product different. Login, payments, email, file storage, hosting and analytics all have solid ready made services. Use them.
Step 6: Decide what you want to learn
An MVP is an experiment. Before you build, write down what result would tell you to keep going and what would tell you to change course. "Ten clinics use it every week for a month" is a clear test. "People like it" is not.
Every project is different, so treat this as a shape rather than a promise. The point is that each day has a clear output, and nothing is added mid week without something else coming out.
What a one week MVP is not
It is not a cut corner on security, and it is not something you would hand to thousands of users on day one. It is a working, focused tool for a small group of early users, built so you can learn quickly and decide where to spend next.
When one week is not realistic
Some products cannot honestly be built in a week. Anything with heavy regulation, complex hardware or deep integration with old systems will take longer. A good team will tell you that upfront rather than promise a date they cannot hit.
Your scoping checklist
- Can you state the problem in one sentence?
- Can you name the one user and their one job?
- Is the shortest path to value three to five steps or fewer?
- Is everything else on the "later" list?
- Do you know what result means keep going, and what means change course?