I Spent 3 Weeks Building a SaaS MVP — Here’s What Actually Worked (and What Didn’t)
Three weeks ago I decided to ship something. Not another prototype, not a “let me check if this works” project. A real product with pricing, a Stripe integration, user authentication, and the whole thing.
I set a hard deadline: 21 days, ship or abandon.
The result? I launched on day 19. Got my first paying user on day 22. Also broke production twice, rewrote the auth system from scratch, and had a moment where I seriously considered deleting the entire repo.
Here’s the honest breakdown.
Why 3 Weeks?
I’ve been building side projects for years, and the pattern was always the same: start ambitious, spend two months on features nobody asked for, then lose momentum and abandon. The last three projects I started never saw the light of day. They’re sitting in private GitHub repos with one commit each.
So this time I forced constraints. Three weeks meant I couldn’t over-engineer. I couldn’t add “just one more feature.” I had to make hard tradeoffs from day one.
The product was simple: an API gateway with usage tracking and billing — exactly the kind of tool I needed myself. If you’ve ever tried to set up usage-based pricing for an API, you know how painful the Stripe metered billing setup is. I wanted to build something that solved that pain.
Week 1: The Trap of Over-Architecting
I started with the best intentions. Set up Next.js, configured TypeScript strict mode, wrote detailed type definitions for every data model. I even spent two hours designing a database schema that would “scale to millions of users.”
That was a mistake.
By day 3, I had a beautiful empty app with perfect types and zero functionality. I was building infrastructure for a product that didn’t exist yet. Classic solo developer trap.
I caught myself when I realized I was writing a migration script for a table I wasn’t even sure I needed. I deleted half the code and started over with the simplest possible approach: SQLite for storage, a single API endpoint, and hardcoded pricing tiers.
The lesson was painful but necessary: your first user doesn’t care about your database schema. They care about whether your product works.
Week 2: The Ugly Middle
This was the worst week. The initial excitement was gone, and the finish line felt far away. I had a basic working prototype by day 7, but it was held together with duct tape. Error handling was minimal. The UI looked like someone dragged Bootstrap elements onto a page and called it a day.
I almost quit twice.
What kept me going was a simple rule: ship one working feature per day. Not perfect, not polished. Working. Day 8 was user signup. Day 9 was API key generation. Day 10 was usage tracking. Each feature took 2-4 hours, and by the end of the week, I had something that could technically be called a product.
The Stripe integration was the hardest part. I’ve integrated Stripe before, but metered billing adds complexity. Every time a user makes an API call, I need to report it to Stripe in real time. If the reporting fails, the billing is wrong. I spent two full days just getting this right. According to Stripe’s own 2025 developer survey, 67% of developers find metered billing integration more complex than standard subscription setup. I believe that number now.
Week 3: Launch Panic
Day 15 hit and I realized I hadn’t thought about launch. No landing page. No documentation. No way for users to find the product.
I spent day 16 writing a landing page. Day 17 writing basic docs. Day 18 setting up email notifications for signups and payments. Day 19 was launch day.
I posted on Hacker News and two indie hacker communities. The response was… quiet. About 40 visitors on launch day, zero signups. That stung.
But here’s the thing: the next day, someone signed up. And the day after that, someone actually paid. My first paying customer was a developer who had the exact same Stripe metered billing pain I had. He found my product through a comment I left on an IndieHackers thread.
One user. One payment. That’s all it took to make the three weeks worth it.
The Numbers (Real Ones)
I track everything, so here are the actual numbers from this build:
Is $29/month a success? Depends on how you look at it. As a business, no. As a proof that I can ship something people will pay for, yes.
What I’d Do Differently
If I did this again, three things change:
First, I’d launch earlier. Day 10, not day 19. The fear of shipping something incomplete is mostly in your head. Users are more forgiving than you think.
Second, I’d skip the database schema design entirely on week 1. Just use whatever gets you to a working prototype fastest. Migrate later if you need to.
Third, I’d start talking about the product before it exists. I spent 19 days building in silence. If I had posted my progress, I might have had users waiting on launch day instead of starting from zero.
Is It Sustainable?
I’m three weeks post-launch now. The product has 5 users, 2 paying. Revenue is $59/month. Not life-changing, but it covers the server costs and then some.
More importantly, I have a real product with real users giving real feedback. One of them emailed me last week asking for a feature I hadn’t considered. I built it in an afternoon. He upgraded his plan the next day.
That feedback loop — ship, get feedback, iterate, get paid — is something you can’t simulate. You have to get out there and do it.
The three-week constraint worked for me. I’ll probably do it again for the next product.
