How I Built My First SaaS in 30 Days

Why I Set a 30-Day Constraint

Plenty of founders spend months polishing products nobody has agreed to pay for. I wanted to avoid that, so I set one rule: ship a usable MVP in 30 days.

The constraint did the work that discipline usually fails to do. Every feature had to justify its existence against a deadline, which is a much harder test than justifying it against my own enthusiasm. Two weeks in, that rule killed a settings page I had already started building.

A month is also long enough to build something real and short enough that you cannot hide. If the thing was not usable by day 30, that was information.

Week 1: Problem Selection and Validation

I picked a problem I kept hitting myself: creating blog cover images was eating too much time every week.

Choosing your own problem has a real advantage and a real trap. The advantage is that you know the workflow, the frustration, and the current workarounds without doing discovery. The trap is assuming everyone else has it too. So before writing code I validated publicly:

• Posted the concept with one clear outcome, not a feature list
• Invited beta signups so interest had a cost, even a small one
• Asked what people used today and what specifically annoyed them about it

Signup interest arrived in under 24 hours, which was enough to continue. The replies were more useful than the count. People described their current workaround in detail, and those descriptions told me which single flow to build.

The question I asked that produced the most useful answers: what do you do today instead? Nobody can reliably predict whether they will buy something. Everybody can describe what they currently do.

Week 2: Stack Decisions, Speed Over Novelty

I chose familiar tools to keep implementation risk low.

• Next.js for product UI and API routes
• Supabase for data and auth
• OpenAI API for the image workflow logic
• Vercel for deployment and preview loops

None of that is interesting, which is the point. Every hour spent learning a new framework is an hour not spent on the thing customers pay for. I had shipped on all four before, so I knew where the sharp edges were: auth session handling, cold starts, and rate limits on the image calls.

The one decision I would defend hardest is using hosted auth instead of building it. Auth looks like a two-day job and is a two-week job once you include password reset, email verification, and the edge cases that only appear with real users.

Save your novelty budget for product value, not infrastructure experiments.

Week 3: Build One Irreplaceable Flow

I built exactly one end-to-end outcome: input a headline, get usable cover images quickly.

What I deliberately skipped:

• User profile systems beyond email and password
• Any analytics dashboard inside the product
• Non-essential account settings
• Team accounts and permissions
• An admin panel, which I replaced with SQL queries for the first month

Each of those is defensible eventually and none of them was the reason anyone would sign up. A narrow core flow also produced clearer feedback, because when there is only one path through the product, every complaint is about that path.

The test I used before adding anything: does this improve the core outcome for the person who signs up tomorrow? If the honest answer required a hypothetical future user, it waited.

Week 4: Launch and First Revenue

Launch was a simple sequence:

1. Invite the beta list personally, in small batches
2. Offer a clear paid plan with one price
3. Keep onboarding friction low, meaning no forced tour and no required profile fields
4. Reply to feedback the same day

First paid users arrived during launch week. Revenue was small, and the signal was not. Someone entering card details for a product that had existed for four weeks tells you more than fifty encouraging comments.

Charging from day one also changed what people told me. Free users report annoyances. Paying users report blockers, and they are far more specific about what they need next.

What Actually Drove Results

Fast feedback loops. Short cycles between build, ship, and learn beat good architecture at this stage. I deployed to production most days, which is only possible with preview deployments and easy rollbacks.

Clear scope boundaries. Every request had to pass the core-outcome test. Saying no early is what made the 30 days possible.

Early monetization. Paid behavior separated curiosity from demand, and it did so in week four instead of month six.

Execution rhythm. Two focused blocks a day beat occasional long sessions. The long sessions felt more productive and produced more code I later deleted.

What I Would Do Differently

Instrument onboarding earlier. I could see that people signed up and could not see where they stalled between signup and first generated image. That gap is the most valuable thing to measure in an early product, and I had to add it retroactively. There is a whole playbook on this in onboarding that reduces time to value.

Prepare launch assets before ship day. I wrote the launch copy on launch day, which is how you end up with a mediocre announcement for a product you spent a month on.

Define retention experiments in advance. I launched with no plan for week two of the customer relationship, so the first month after launch was reactive.

Launching fast is good. Learning fast after launch is where the growth actually starts.

Post-Launch Retention Checklist

The first month after launch is where most of the learning sits. What mattered:

• Track time to first value, meaning signup to first successful output.
• Pull the top three activation blockers straight from support conversations, not from guesses.
• Ship one onboarding improvement per week, small enough to actually finish.
• Run one pricing or packaging experiment with success criteria written down beforehand.

A fast launch without a retention loop creates noisy growth. A fast launch with one creates compounding growth.

What I Watch Weekly Now

Four numbers: activated users, retention by cohort, support ticket themes, and trial-to-paid trend. Those four reveal where to ship next faster than any broad dashboard.

You do not need a real analytics platform in week one. You do need it by the time you have enough users for patterns to mean anything, and picking one before then usually wastes money. I compared the options in product analytics tools by stage, including which free tiers hold up.

One Rule That Helped Most

Every week I shipped one friction-removing change before adding any new feature. That kept the product improving for the people already using it rather than expanding for people who might show up later.

The friction changes were small and unglamorous: fewer required fields, clearer error messages, a faster path from login to the one screen that mattered. None of them would appear on a changelog anyone cares about. Together they did more for retention than any feature I shipped in the same period.

The rule also works as a filter on your own enthusiasm. New features are more fun to build, which is exactly why they win by default unless you force the other work to go first.

Related Guides

• The startup stack I would pick again
• Onboarding that gets users to value faster
• Product analytics tools, ranked by stage
• Product-led or sales-led: a decision framework

Final Take

The 30-day build worked because the goal was validated progress rather than a finished product.

If you are starting your first SaaS, pick the one flow that has to work, cut everything else, and put a price on it before you feel ready. Set a date, tell someone about it, and let real user behavior decide what comes next.