A weekend MVP is not a polished product. It's not a product you'd send to a journalist. It's not something with a settings page or onboarding email sequence or documentation.
It's a thing that works, that real people can use, that generates a real reaction -- positive or otherwise -- from the people you show it to.
That's the correct definition. Everything you build toward that definition is in scope. Everything else can wait.
The founders who ship something in 48 hours don't move faster because they're more productive. They move faster because they've made all three of these decisions correctly: they picked something that can be built in 48 hours, they eliminated every feature that isn't required for the thing to work at all, and they used tools that give them an 80% head start on every technical requirement.
Here's the playbook, hour by hour.
Before You Start: The 30-Minute Scope Document
Before you open your IDE or your design tool, spend 30 minutes writing answers to four questions.
What is the single thing this product does? Not the feature list. The one sentence. "It lets a freelancer send an invoice to a client and get notified when the client views it." That's the single thing. Everything else is secondary.
What does the user do first, second, and third? Map the core user journey in three to five steps. If you can't describe it in five steps, the scope is too wide.
What is explicitly out of scope for this weekend? Write a "not building this weekend" list. It should include: user settings, admin dashboard, password reset flow, team accounts, API documentation, mobile app, integrations. All of these can exist later. None of them are required for the core thing to work.
How will I show it to five real people by Sunday evening? Think about this before you start building. The test of whether the weekend was successful is a human reaction from a real person. If you don't know who those five people are before you start, the weekend will end with a product you haven't shown anyone.
The scope document output: one sentence, five-step journey, explicit not-building list, five specific people to show it to. Write it. The writing is not bureaucracy -- it's the first constraint that makes the 48 hours viable.
Friday Night (2 Hours): Decisions
Friday evening is for decisions, not building.
Choose your stack by a single criterion: what are you fastest in right now, today? Not what is most scalable. Not what you've been meaning to learn. The stack you already know.
If you're fastest in Next.js with a Postgres database, build with that. If you're fastest in Django, build with that. The weekend is not the time to learn a new framework. The 20% of time you'd spend understanding unfamiliar patterns is 20% of your 48-hour budget.
Choose your deployment infrastructure Friday night: Don't make this decision during the build -- you'll waste build time. Pick now. A sensible default for most web products: Vercel for the frontend/API layer, Supabase (free tier) for database and authentication, Stripe for payments if the product needs them. Everything should be configured and connected before Saturday morning arrives.
Connect your repository to Vercel before you go to sleep. Run the "hello world" deployment. Confirm the database connection works. When Saturday morning starts, you should be able to write code and have it live within minutes.
One more Friday decision: how will users access the product? Public access (anyone with the URL), email-gated (requires account), or invitation-only (you manually add the five people you're showing it to)? This decision affects the first features you build Saturday morning. Make it Friday night.
Saturday Morning (4 Hours): Foundation
The foundation is the infrastructure that everything else sits on. Build only what is required for the core thing to work.
For most web products, this means: a working data model (your database schema with the tables the core feature needs), authentication if users need accounts, and the one primary page of the product -- the page where the core thing happens.
The temptation during foundation building is to also add the header, the footer, the navigation, the styling system. Defer all of this. An unstyled page that does the core thing is more valuable at the 48-hour mark than a beautifully styled page that doesn't.
By the end of Saturday morning, you should be able to navigate to your deployed URL, complete the primary user action, and see a result -- even if that result is rough and the page looks like a text editor.
If you reach Saturday midday and the primary user action doesn't work end-to-end, the scope was too wide. Cut something. The core thing must work by Saturday midday.
Saturday Afternoon (4 Hours): The Core Feature
With the foundation working, Saturday afternoon is for the specific feature that delivers the most value.
The core feature is the one thing that makes a real person think "this would be useful." Not the feature that makes the product complete. The feature that generates the reaction you're building toward.
For an invoice tool: the feature is seeing a real invoice rendered and having a link to share it. Not the styling of the invoice. Not the client portal. The working invoice with a shareable link.
During the core feature build, you will encounter decisions you didn't anticipate. The scope document is your filter: does this decision need to be made for the core feature to work? If yes, make it. If no, put it on a list and keep building.
The "keep building" discipline in the afternoon is the most important execution skill of the weekend. Every distraction -- a nicer UI, a more complete data model, an additional field you think would be useful -- takes time you don't have.
Saturday Evening (2 Hours): Ship and Tell
By Saturday evening you have a thing that works. It's rough. It might look terrible. Ship it anyway.
Deploy. Get the URL. Send it to two of your five people with a message that sets the right expectation: "This is a very rough first version I just built. Would love your reaction to the core thing -- does it work the way you'd expect?"
Do not say "I spent the whole weekend on this." Do not over-explain what's missing. Show them what exists and ask for honest reaction.
Then close the laptop for two hours. Eat. Leave the house. Your brain needs the break before Sunday.
Sunday Morning (4 Hours): First Feedback and Iteration
Sunday morning opens with whatever responses came from Friday's recipients. Read them before you build anything.
The responses will fall into predictable categories:
"I couldn't figure out how to [do the thing]" -- a flow problem. Fix this first. If the core thing is hard to do, nothing else matters.
"I did the thing but expected [different result]" -- an expectation gap. This might be a features thing you can't fix this weekend, or it might be a framing issue you can address with two lines of copy.
"It worked! But what does [feature] do?" -- confusion about something that exists. Fix the language, not the feature.
"It worked and I would use this if it also had [X]" -- this is the most valuable type of feedback. Write it down. Don't build X this weekend. Validate that three people independently name X before you build it.
Spend the first two hours of Sunday on the fixes that address your flow problems. Spend the next two hours showing the remaining three people -- either the updated version synchronously (call them) or by sending them access with a brief video walkthrough.
Sunday Afternoon (2-3 Hours): Documentation and Decision
Sunday afternoon is for two things.
Minimal documentation: One page (could be a Notion doc, could be a README, could be a five-bullet description on the page itself) that explains what the product does and how to use the primary feature. This is not for the current five people -- they've seen it. It's for the next people you'll show it to next week.
The Monday decision: Before Sunday ends, write down: what was the primary reaction from the five people, what the most requested missing feature was, and one sentence about whether you want to keep working on this or not.
The honest version of this decision is not "did the five people like it?" It's "did the five people use it in the way I expected and find it useful enough that they'd tell someone else?" If yes, you have something worth continuing. If no, the weekend still wasn't wasted -- you learned what didn't work in 48 hours instead of four months.
The Four Traps That Kill Weekend Builds
Scope expansion Saturday morning: You decide to add one feature before the foundation is done. That one feature takes two hours. The foundation isn't done by midday. The core feature isn't done by Saturday evening. Sunday is recovery, not iteration.
Styling before function: You spend three hours Saturday afternoon making the UI beautiful. The core feature still doesn't work. Beautiful non-functional software is worthless.
Not shipping because "it's not ready": The point of the weekend is the human reaction. An unshipped product gets no reactions. Ship the rough version. The rough version that five people have seen is more valuable than the polished version you're still refining Monday morning.
Showing it to the wrong five people: Friends who don't have the problem will give you encouraging feedback that tells you nothing. Show it to five people who actually have the problem the product addresses. Their confused silence or genuine interest is the data. Your friends' supportive enthusiasm is noise.
What the Monday Morning Means
The weekend MVP is the beginning of a decision, not the end of one.
Monday morning you have: a working thing, reactions from five real people, and a clearer sense of whether the problem you're solving produces real behavior change when a solution is available.
That is more than most founders have after four months of building. It doesn't mean the thing is finished. It means the signal has been generated.
What you do with the signal is the next question. But you can't answer it without the thing existing first.
Start Friday night. Ship Saturday evening. Learn Sunday. Decide Monday.
That's the 48 hours.
Ready to validate your idea?
Start using WarmLaunch today to grow your waitlist.