The One-Week MVP

Day 1 — Find the pain, not the idea

The shift

You are attached to your idea. Drop it. Ideas are cheap and untestable; pain is specific and testable. "An app for freelancers" is an idea. "Freelancers re-type the same three paragraphs into every proposal and it takes twenty minutes" is a pain. You can build for the second one. You cannot build for the first.

The trap is that your idea feels like the valuable part. It is not. The valuable part is a person with a problem expensive enough that they would pay to make it go away.

The move

Write one sentence in this exact shape, and do not move on until it is true and specific:

[A specific person] wastes [time or money] doing [a task], and today they solve it by [a painful workaround].

If you cannot fill every bracket with something concrete, you do not have an MVP yet — you have a hunch. The fastest way to fill the brackets is not to brainstorm. It is to go where that person already complains: a subreddit, a Slack community, a Facebook group, the replies under a relevant post. People describe their pain for free, in their own words, every day.

Use AI to compress that noise into signal:

Copy this

Here are 30 posts/comments from [where your target person hangs out].
[paste them]

Read them as a product researcher. Give me:
1. The 5 problems that come up most, ranked by how often and how
   angrily people mention them
2. For each, the exact words people use to describe it
3. Which one someone would most plausibly pay to remove, and why
4. The problems that sound big but are actually just complaints
   nobody would pay to fix

Be skeptical. I am about to spend a week on one of these.

Done when

You can say your one-sentence pain out loud to a stranger in your target group and they say "yes, that is exactly it" — not "interesting", not "makes sense". Exactly it.

Day 2 — Test the door before you build the room

The shift

You believe you have to build the thing before anyone can want it. You do not. You have to make the promise of the thing, and see if anyone reaches for the handle. If nobody reaches for a door, there is no point building the room behind it.

This is the single most skipped step in building a product, and it is the one that saves the most months.

The move

Run one of two tests, both doable today, neither requiring your product to exist.

The fake-door test. Build a single landing page that describes the product as if it were real: the promise, who it is for, what it does, one clear button — "Get early access" or "Start free". The button leads to a short form or a "we are launching soon, leave your email" screen. Then drive a small trickle of the right people to it and measure: of the people who land, how many reach for the handle?

The concierge test. Better still for a service-shaped product: offer to solve the pain manually, by hand, for a few real people. No software. You are the software. "Send me your messy data and I will send back the clean file by tomorrow." If people say yes and value the result, you have proof the outcome is wanted before you have automated a thing.

Copy this

To build the fake-door page without a designer (this connects straight to Day 3):

Build me a one-page landing page. Do not ask me to code.

Product: [name]
For: [the specific person from Day 1]
The promise: [the pain, removed — in their words]
One primary button: "[Get early access]" → collects an email
Below: 3 short lines on how it works, and one line on who it is for

Tone: plain, concrete, no hype. Make the pain in the headline,
not the features. Give me something I can put online today.

Done when

Real people who are not your friends have either left an email on the fake door, or said yes to the concierge offer and valued what you delivered. A friend saying "cool idea" is not a signal. A stranger giving you their email, or their time, is.

Day 3 — Vibecode the thin version

The shift

You think building the product means building the product — accounts, database, settings, the second feature, the polish. In week one, all of that is procrastination wearing the mask of progress. The thin version is not a worse product. It is the correct product for right now: one screen that does the one thing your pain sentence promised, with real data, for real.

This is the move that used to require hiring a developer or learning to code for a year. It no longer does.

The move

Do not describe the app. Describe the problem and the person, and let the AI propose the build — then keep it brutally small.

1. One screen, one job. The single most valuable action, and nothing else. Not the roadmap. The one thing.
2. Real input, real output. It has to actually do the job on real data, not mock it. A tool that fakes the outcome teaches you nothing.
3. Ugly is fine. No settings, no accounts, no onboarding. If you can use it, it is done.
4. Ship it somewhere you can send a link. It has to be reachable by a stranger with a URL, or you cannot run Day 4.

Copy this

I want to build the thinnest possible version of a tool. Do not
write code yet.

The problem: [your Day 1 pain sentence]
The one action that solves it: [the single thing the tool does]
Input the user gives: [what they paste / upload / type]
Output they get back: [the finished result]

Interview me until you could build the simplest version that does
exactly that one action on real input — one screen, no accounts,
no settings. Ask one question at a time. Then show me the plan and
wait for my go-ahead before writing anything.

Done when

You can send one link to one stranger and they can complete the core action — get the real result — without you sitting next to them explaining it.

Day 4 — Put it in front of five people

The shift

You want to launch to everyone. Resist it. Five real users watched closely will teach you more than five hundred anonymous signups you cannot talk to. At this stage you are not looking for growth. You are looking for the truth, and the truth lives in watching a real person get stuck.

Surveys lie, because people are polite. Behaviour does not lie. Someone telling you they would use it is worth nothing next to someone actually using it.

The move

Find five people who have the pain from Day 1 — the fake-door emails and the concierge customers are your list. Get the tool in front of each of them, and if you possibly can, watch them use it: a screen-share, a call, in person. Say almost nothing. Do not guide them. Watch where they hesitate, what they misunderstand, where they light up, and the exact moment they would have given up if you were not there.

One question does more work than any survey, and you ask it only after they have used it:

"How would you feel if you could no longer use this?"

The people who answer "very disappointed" are your product. The ones who shrug are not, and no amount of features will convert a shrug.

Copy this

After the five sessions, turn what you saw into a decision:

Here are notes from 5 people using my MVP: [paste what you observed —
where each got stuck, what they said, whether they would miss it].

Give me:
1. The single friction point that showed up most — the thing to fix first
2. Anything people expected the tool to do that it did not
3. Who lit up and who shrugged, and what separates the two groups
4. Your honest read: is there a "very disappointed" core here, or am I
   forcing something people do not actually want?

Done when

At least a few of your five would be genuinely disappointed to lose the tool, and you can name the one thing to fix before anyone else touches it.

Day 5 — Refuse to build the rest

The shift

Now the danger inverts. You have a working thin thing and a few people who like it, and every instinct screams "add the features". That instinct, followed now, is how one-week MVPs become one-year projects that never ship. Almost everything on your original feature list will turn out not to matter. The discipline that got you here — smaller, thinner, one thing — is the same discipline that carries you forward.

The move

Take your feature wish-list and sort every item into exactly one of three buckets:

• Fix — the one friction point from Day 4 that stops people getting the value. There is usually only one. Do this.
• Later — real, but not what is blocking anyone today. Write it down and walk away.
• Never — the thing you wanted because it is fun to build, not because a user needs it. Be honest; this bucket is bigger than you think.

Then do only the Fix. One thing. Ship it. The rule for the whole first month is: extend by complaint, not by imagination. You only build the next thing when a real user hits a wall and tells you — "when I do X it does Y and it should do Z." That sentence is your entire roadmap.

Copy this

Here is my feature wish-list for the MVP: [paste it].
Here is the one friction point real users actually hit: [from Day 4].

Sort every feature into Fix / Later / Never:
- Fix = directly unblocks the value for current users
- Later = real but blocking nobody today
- Never = I want it because it is interesting, not because a user needs it

Be ruthless about the Never bucket. Then tell me the single thing
to build this week and nothing else.

Done when

Your list has exactly one item in "Fix", you have built it, and you have said no — out loud — to at least three things you were itching to build.

Day 6 — Charge for it (yes, already)

The shift

You think it is too early, too rough, too small to charge. The opposite is true: money is the only unfaked signal. People will give you praise, emails, and encouragement for free. The moment you ask them to pay, the polite ones vanish and the real ones stay — and the real ones are the only data that matters. A free user tells you nothing about a business. A paying one tells you everything.

Charging is not about the revenue this week. It is the sharpest validation test there is, run early enough to still matter.

The move

Put a price on it, even a rough one, even a manual one. You do not need billing infrastructure. You need a way to take money and a reason for someone to hand it over.

• Pre-sell. "I am building this. It will be [price]. Pay now and you are in for life / for the first year." If people pay before it is finished, you have the strongest signal a product can have.
• Charge for the outcome, not the software. Especially coming from freelancing: people already pay you for results. Package the result, not your hours. The tool is just how you deliver it faster.
• Manual payment is fine. A payment link, an invoice, a "send me [amount] and I will turn on your access." Automate collection later, once someone has actually paid.

Copy this

I am pricing my MVP. Context:
- What it does: [the one job]
- Who it is for: [Day 1 person]
- What the pain costs them today: [time/money of the workaround]
- What they pay now to solve it, if anything: [alternatives]

Give me:
1. Three price points and the logic for each (anchor, target, floor)
2. Whether to price per outcome, per month, or one-time — and why
3. The exact one-paragraph pitch I send to ask for the money,
   in plain language, no hype

Done when

At least one person you are not related to has paid you real money — or committed to — for the thing. That sentence changes everything about the conversation you are having with yourself.

Day 7 — Read the one signal that matters

The shift

You will be tempted to judge the week by vanity: signups, likes, "great idea" replies. Ignore all of it. There is one signal that tells you whether to keep going, and it is not the size of your list. It is whether the people who used it come back, and whether the people who paid would be upset to lose it. Everything else is noise dressed up as progress.

The move

Sit with the week's evidence and answer one question honestly: is there a small group of people who genuinely do not want to give this up?

• If yes — even five people, even scrappy — you have something real. Now, and only now, does it make sense to build the second feature, automate the manual parts, and think about growth. You have earned the right to scale because you validated first.
• If no — people tried it, shrugged, did not return, would not pay — that is not failure. That is the cheapest possible answer to the most expensive possible question, delivered in one week instead of one year. Take the pain sentence back to Day 1 and aim it somewhere else. You lost days, not a year of your life.

The whole point of doing it in a week is that a "no" costs you almost nothing. Most people spend a year earning the same answer.

Copy this

Here is everything from my week: [signups, who came back, who paid,
who would be "very disappointed" to lose it, what people said].

Cut through my optimism. Answer one thing: is there a real, if small,
group who genuinely do not want to give this up — enough to build on?
Or am I about to spend three months forcing something the evidence
is quietly telling me to drop?

Give me the honest read, then the single most important thing to do next.

Done when

You can say, with evidence and not hope, either "yes, these specific people need this, I am building the next thing" or "no, and I found out in a week." Both are wins. Only the year-long maybe is a loss.

The whole thing on one page

How to actually run this

One day, one move, starting Monday. The days are not sacred — if Day 2 tells you nobody wants the door, stop, and you have saved yourself the other five. That is a feature of the plan, not a failure of it.

The people who get nothing from documents like this read all seven days, feel informed, and go back to building the version in their head. The test is not whether you understood Day 3. It is whether, by next weekend, a stranger has touched your thin thing and told you the truth.

Build with AI. Think like a founder. Both halves matter, and this is where they meet.

FiscEdge Academy — Build with AI

More playbooks, tools and workflows for founders: academy.fiscedge.com

This playbook is free to share. If someone forwarded it to you, get the rest of the series at academy.fiscedge.com.