I've watched dozens of developers — smart ones — spend three months planning a side project that never ships. They pick the perfect stack, diagram the perfect architecture, and open a Notion doc with perfect headers. Then life happens. The project dies in draft.
I used to be that developer. Then I flipped the script. Now my rule is simple: if it's not live in a weekend, it's not worth building. Here's exactly how I do it.
01. Constrain the idea to its core loop
Every product has one core loop — the single action that delivers value. Everything else is a feature. Before I write a single line of code, I write one sentence: 'A user can [do X] and get [Y result].' If I can't write that sentence, I don't have a product. I have a vibe.
If you can't describe your MVP in one sentence, you're not ready to build it. Clarity first, code second.
02. Pick boring tech on purpose
New tech is a trap for side projects. Every hour spent reading docs for a shiny new framework is an hour not shipping. My default stack for a weekend MVP is always Next.js App Router, Tailwind, Prisma + Supabase, and Vercel. I could build this in my sleep. That's the point.
# My 60-second project bootstrap
npx create-next-app@latest my-mvp --typescript --tailwind --app
cd my-mvp
npx prisma init
# Push to GitHub, connect Vercel — done.
# Now go build the actual thing.03. The Friday Night / Saturday / Sunday framework
- Friday night (2 hrs): Scaffold, deploy a blank app to prod, wire up auth. Having a live URL from hour one is a psychological cheat code.
- Saturday (6–8 hrs): Build only the core loop. Nothing else. No settings page, no profile page, no dark mode toggle.
- Sunday morning (3 hrs): Polish the one happy path. Fix the three most embarrassing bugs. Write the README.
- Sunday afternoon: Share it. Anywhere. Literally anywhere. Ship or delete.
04. The features you skip on purpose
Here's what I explicitly cut from every MVP: user settings, email notifications, admin dashboards, error tracking, analytics, tests, and any page that isn't the core loop. I keep a 'V2' doc and dump every cut idea there. It makes cutting feel productive instead of like giving up.
A 'V2' doc is not a backlog. It's a graveyard with good lighting. Most of those ideas will never ship — and that's fine.
05. Shipping IS the learning
The feedback you get from one real user using a live product is worth more than one hundred hours of planning. You will learn things about your own idea in the first 24 hours after launch that no amount of research could surface. Ship ugly. Ship incomplete. Ship now. Iterate forever.
The projects I'm proudest of started as ugly weekend hacks. The ones I regret are the perfectly planned ones still sitting in a private GitHub repo. Done beats perfect every single time.