From idea to MVP in a weekend
A realistic two-day plan for shipping something small enough to finish and real enough to test.
Weekend builds fail on Saturday morning, not Sunday night. The failure is always the same: the scope was set by enthusiasm instead of by the clock. Here's the plan we use, hour by hour.
Friday evening: cut until it hurts
Write the one sentence a user would say after using it. Then list every feature you imagined and delete everything that isn't required for that sentence to be true. Accounts, settings, dashboards and dark mode are almost never required. Aim for one screen doing one thing.
Saturday morning: the ugly path
Build the core interaction with no styling at all. Input, action, result. If the core interaction isn't interesting when it's ugly, no amount of design will save it, and you have just learned that on day one instead of day thirty.
Saturday afternoon: make it real
- Real data instead of placeholders.
- Handle the empty state and the error state — those are half of real use.
- One pass of styling using a single accent colour and one font.
- Deploy it. A live URL changes how you think about it.
Sunday morning: the edges that matter
Loading states, a sensible page title, mobile layout, and a way for someone to contact you. Skip analytics dashboards, onboarding tours and admin panels. You have no users yet; you cannot administer them.
Sunday afternoon: put it in front of five people
Not a launch, five people. Watch them use it without explaining anything. Every hesitation is a bug in your copy. This one hour is worth more than the whole weekend of building, which is exactly why people schedule it last and then skip it.
What 'done' means
Done means a stranger can complete the main action without you in the room. Not polished, not scalable, not feature-complete. If you're still adding features on Sunday night, you're not building an MVP, you're avoiding feedback.
The point of a weekend build is not the build. It's the conversation you can have on Monday.