Everything in this series so far has been one component. This is the order you assemble them in, and where the weekend estimate holds versus where it quietly doesn’t.
What You’re Building
A SaaS with accounts, a core feature, usage limits, and paid plans. The specific product doesn’t matter — the structure is the same for most of them.
Pick a Boring Stack
Next.js App Router, TypeScript, Tailwind, Supabase for database and auth, Stripe for payments, Resend for email, deployed on Vercel.
Not because these are objectively best. Because they’re heavily documented, which means AI reproduces them accurately. A less common stack means more hallucinated APIs and more time debugging code that references functions that don’t exist.
Save the interesting technology choices for when you have customers.
The Build Order
The order matters more than the individual steps, because it determines how early you find out the idea is wrong.
Day 1 morning — the core feature, alone
No auth. No database. No payments. Hardcoded data.
Build the core feature as a single page with hardcoded sample data. No authentication, no database. I want to see the main thing working before adding anything around it.
This is the only part of your product that’s actually yours. It’s also the part most likely to reveal that the idea doesn’t work — and finding that out before you’ve built billing is worth a lot.
Use it yourself. If it’s boring with perfect fake data, it’ll be boring with real data.
Day 1 afternoon — data and auth
Add Supabase Auth: email/password plus Google. Protect the app routes server-side. Create the schema for the core feature with a user_id column on every user-owned table. Enable RLS with policies filtering on auth.uid(). Give me the SQL.
Follow vibe code user authentication here — this is the highest-risk hour of the whole build, and the ownership gap it describes will be present.
Commit. Test with two accounts before moving on.
Day 2 morning — make it a real app
Add the dashboard shell: sidebar nav, user menu, settings page. Wire the core feature to real data. Add loading, empty, and error states everywhere.
Empty states matter more than they sound. Every new user sees them first, and an app that looks broken on first load loses people at the moment they’re deciding.
Day 2 afternoon — limits and payments
Add plan tiers: free with a usage limit, pro unlimited. Enforce limits server-side with a canAccess helper. Add Stripe Checkout for the pro plan with a signature-verified webhook that grants access.
Stripe checkout and pricing page cover this properly. Read the webhook.
Day 3 — the part everyone skips
Onboarding, transactional email, and the security review.
Add an onboarding flow for first-time users. Send a welcome email. Add email notifications for the key events in the product.
Then stop building and audit. Vibe coding security is the checklist. Two accounts, try to reach each other’s data, check every endpoint directly.
This day is not optional and it’s the one that gets cut.
Where the Weekend Estimate Breaks
Three things reliably take longer than expected.
Edge cases. The happy path works on day one. What happens when someone hits their limit mid-action, or their card fails, or they cancel and resubscribe? Each is small; together they’re days.
Email deliverability. Sending is easy. Landing in the inbox needs SPF, DKIM, DMARC, and a sending subdomain with some reputation. Set it up early so it’s warm when you launch.
The security review. Genuinely a day if you do it properly, and it’s the difference between a demo and something you can hand to strangers.
A realistic schedule: working MVP in a weekend, launchable product in two weeks.
What to Leave Out
Everything not on this list:
- Teams and multi-user workspaces
- Roles and permissions beyond user/admin
- An API for customers
- Integrations
- Mobile apps
- A settings page with thirty options
- Dark mode
- i18n
Every one of these is a reasonable thing to want and none belong in an MVP. They multiply the surface area of a product nobody has confirmed they want yet.
Before Real Users
- Two-account test: no cross-account data access anywhere
- RLS enabled on every table
- No secrets in Git history or the client bundle
- Rate limiting on all public endpoints
- Stripe webhook verifies signatures, handles duplicates
- Access granted in the webhook, not on redirect
- Plan limits enforced server-side
- Email deliverability configured and tested in Gmail and Outlook
- Error monitoring installed (Sentry)
- Analytics installed
- Database backups on
- Privacy policy and terms published
- Tested on a real phone
- A way for users to contact you
That last one gets forgotten constantly. Early users will find bugs, and you want them telling you rather than leaving.
The Honest Assessment
AI genuinely collapses the time from idea to working product. What used to be a month is now a weekend, and that’s a real change rather than hype.
What it doesn’t change: whether anyone wants it. The build was never the hard part of a SaaS — distribution and product judgment were, and they still are. You’ve now got a much faster way to find out you were wrong, which is valuable precisely because it’s cheap.
Build the MVP in a weekend. Spend the next month talking to people about whether it should exist.
The Full Series
Foundations: What is vibe coding · How to vibe code · Best tools · Security · What it’s good at · The criticism · Lovable review
Components: Landing page · Waitlist · Authentication · CRUD app · REST API · Dashboard · Admin panel · Pricing page · Stripe checkout
Complete builds: URL shortener · Link-in-bio tool · Booking app · Invoice generator · Blog with CMS