An MVP in one weekend.

You can build a working MVP with AI in one weekend if you keep it to one problem, one kind of user and one core flow. Spend Friday evening cutting scope. Spend Saturday building with an AI agent in small, tested steps. On Sunday, publish it and watch five real people use it.

AI makes the building fast. The hard parts are deciding what to build and keeping strangers’ data safe. This plan covers both, with prompts to copy and a checklist for each day.

01What is an MVP, and what is it not?

A waitlist page tests interest. An MVP goes one step further: someone can actually do the thing, even if it is rough and slow.

Doing parts by hand is allowed. If your app promises a weekly report, write the first ten yourself and send them by email. Automate that part only after people ask for more.

02Friday night: scope one problem, one user, one flow

Friday decides the weekend. Tonight’s job is to make the feature list shrink.

1. 01

   Write the problem in one sentence

   Use this shape: “When [situation], [type of person] struggles to [task], so today they [workaround].” If you cannot name the workaround, you may not have a real problem yet.

2. 02

   Pick one user

   Not “small businesses”, but “a dog groomer who books clients by text message.” A narrow user makes every later decision easier, including who to ask for feedback.

3. 03

   Draw the core flow in five steps or fewer

   Write the path from arrival to value. For the groomer: sign up, add a client, send a booking link, the client picks a time, the groomer sees it. Anything off this path waits.

4. 04

   Write a “not this weekend” list

   Payments, teams, settings, a phone app, dark mode. Writing ideas down makes them easy to drop, because you know they are not lost.

Then ask the AI to push back. Models cut scope well when you make that the job.

I want to build an MVP this weekend. My idea: [describe it in a few sentences].
Act as a skeptical product coach. Reduce it to:
1. One user, described specifically.
2. One problem, in one sentence.
3. One core flow of five steps or fewer.
4. What to cut, and what I could do by hand instead of building.
5. The one question this MVP should answer by Sunday night.
Be blunt. If it is too big for a weekend, name the slice to build first.

03Saturday: build your MVP with AI, one step at a time

Start with a plan, not code. Ask the agent for the simplest setup and a list of small steps, and read it before anything gets built. A plan is cheap to change. A half-built app is not.

Here is my MVP brief: [paste Friday's page].
Before writing any code, propose:
1. The simplest common setup for this, with a hosted sign-in service and a hosted database. Explain each choice in one line.
2. What data we will store, as a short list of tables and fields.
3. A build plan of small steps. I must be able to check each step in the browser.
Do not start building until I reply "go".

Choose boring, popular tools. Models write better code for widely used tools, and you will find answers when something breaks. Then build one step per prompt:

Build step [number] of the plan, and only that step. When it works:
- Run it and fix any errors you find.
- Tell me how to test it by hand, in three steps or fewer.
- List anything you skipped or assumed.
Do not touch files that this step does not need.

Test each step yourself before asking for the next. When it works, save a checkpoint. In a code project that means a git commit: a snapshot of every file you can return to. If a later change breaks something, you roll back in seconds instead of arguing with the model.

This rhythm of small steps and quick checks is the heart of our AI pair programming workflow. If you would rather not see code at all, our guide to building an app without coding compares the tools that hide it.

04What to skip, and what you must never skip

A weekend MVP can be rough almost everywhere, but not careless with other people’s data. The moment a stranger signs up, you hold something that belongs to them.

Access rules deserve a closer look, because the mistake is easy to miss in code you did not write. The OWASP Top 10, the industry’s standard list of web security risks, ranks broken access control first in its 2025 edition. It means one user can see or change another user’s data, and OWASP found some form of it in every application it tested.

If you use Supabase, a popular hosted database, the fix is called row-level security: rules that decide which rows each user can read or change. Its docs are blunt: turn it on for every table your app can reach, then add rules such as “users can only see rows they own.”

Review this app as a security engineer before real users sign up. Check, then fix:
1. Can a user read or change someone else's data by changing an ID in a link or request? Try it.
2. Does every database table have rules that limit each user to their own rows?
3. Is any secret key visible in browser code or saved in the project files?
4. Is every form input checked on the server, not only in the browser?
List what you changed and anything you could not fix.

05Sunday: publish and put it in front of five people

Fix the three worst rough edges, not thirty. Then write a one-screen landing page: who it is for, the problem, what it does and one button. Our guide to landing pages that convert has the details.

Publish on a real address before lunch, so people can open it on their own phones. First launch? Here is how to put a website online, domain and all.

Why five? Jakob Nielsen’s research found that five users reveal about 85 percent of a design’s usability problems. After that, each new person mostly repeats what you already saw.

1. 01

   Send the link, then stay quiet

   Ask them to do the core task while thinking out loud. Do not explain anything. When you itch to help, note what confused them instead.

2. 02

   Ask about their past, not your idea

   “When did this last happen to you? What did you do about it?” That is the core of Rob Fitzpatrick’s book The Mom Test: facts about the past are useful, while opinions about the future are mostly politeness.

3. 03

   Ask for a small commitment

   End with an ask that costs them something: using it with real clients this week, or paying a small fee. A yes that costs nothing is not a yes.

06How do you know if your MVP worked?

Judge by what people did, not what they said. Sort your notes into two columns.

Strong signals from even two of five people justify a second weekend. Pull the next item off your list and build it the same way. If those signals are strong enough to think about charging, our guide to building a SaaS with AI covers pricing and your first ten customers.

Mostly weak signals mean the problem or the user was wrong. Change one and run the weekend again. You learned that in two days instead of six months.

07FAQ

Next, learn what vibe coding is and where it breaks, or pick a tool with our AI website builders comparison.