Home

Bootstrapping a New SaaS

So you want to build a SaaS? This is the process I follow systematically to get a new SaaS off the ground as quickly as possible.

The Excitement of Building Something New

The thing is, building a SaaS isn't just coding. It's everything. One day you're debugging an authentication issue, the next you're trying to figure out why the DNS isn't resolving for your domain. You become a developer, marketer, support person, all at once.

But here's the thing - that's what makes it addictive. Every project teaches you something new. Sometimes it's learning about DevOps, other times about Marketing and finding leads on Reddit and Linkedin, and other times drafting Terms of Service and Privacy Policy documents for your own protection.

It's a lot of fun 😅

How I Research the Market

Reddit is where people complain about stuff that either doesn't work or doesn't exist. And complaints = opportunities. I'll spend hours going through subreddits related to whatever topic I'm interested in.

I also check what other people are building. r/SaaS and r/startups are great for this. Sometimes you'll see 5 people building the same thing, which tells you either the problem is real or everyone's copying each other.

Quick note: I stick to what I know. My domain is tech, so I build for tech people and tech problems. I avoid industries I know nothing about - biotech, finance, law, hospitality. Sure, there might be great opportunities there, but you cannot build a great product unless you have domain knowledge.

Validation with a Landing Page

Okay, so I found a problem that seems promising or interesting. Now what? I create a landing page for quick validation.

Here's my setup: I use Next.js, deploy it on Cloudflare Workers (it's basically free, fast and has great infrastructure), and use Cloudflare D1 to save emails. Nothing fancy. The page just says:

"Hey, I'm building this thing that solves your problem. It will do this, that and other things. Drop your email if you want early access."

Then I add Google Analytics and Microsoft Clarity. Why? Because I want to see if people actually care. Are they reading the page? Are they signing up? Or are they bouncing after 2 seconds? This whole thing takes me a couple of hours.

The PRD to Guide the Development

I will admit, I don't wait for many sign-ups to start working on the PRD. 😅 Like I said, if the problem is interesting, I'll start working on it as soon as I see a little bit of interest. I consult my good old buddy Claude and we spend a few hours discussing and brainstorming about features, target customers, pricing strategy, the feasibility of the product and technical challenges that I might not have thought about.

The document is usually a 2 page document with the following sections:

  • •What problem am I solving?
  • •Who has this problem?
  • •How will they use it? (the actual workflow)
  • •What's the bare minimum that brings the most value?
  • •The pricing strategy (subscription based?)

Building the MVP in 1-2 Months (No More!)

Here's my rule: if it takes more than 1-2 months, I'm building too much.

But here's the important part - fast doesn't mean crappy. I still care about the user experience. A lot!!!.

I'd rather have 3 features that work really well than 10 features that are kinda broken. Users will forgive you for not having every feature, but they won't forgive you for wasting their time with buggy, broken software.

Beta Release (Let Your Users Break Things ) 😬

When I'm ready to launch, I always call it a beta. It sets expectations and people are more forgiving. Plus, beta users are amazing for finding bugs and stress test your product. These people are doing you a favor - they're your free QA team.

This is especially important when you're dealing with stuff like multi-tenancy, roles, integration of 3rd party services, etc. You think you've covered all the edge cases? Think again. Better they find it than a paying customer later.

Going Live (Now the Real Work Starts)

Building was the easy part. Now you have to find actual customers. Marketing is where most developers struggle (myself included).

Will elaborate on this in another post. This is not relevant to the main topic of this post.

My Tech Stack (What Actually Works)

Here's what I use and why:

  • •
    Next.js - React + SSR + App Router + Server Actions? 🤓
  • •
    Prisma + Supabase - Prisma DX is unmatched. Supabase for managed Postgres instance with high availability (and backups).
  • •
    Stripe - Great developer tools with test-mode and CLI. Love their Customer Billing Portal.
  • •
    Clerk - Very generous free tier, social logins, user management - all handled 🤷.
  • •
    Resend - For sending emails that don't end up in spam (don't use your own email provider). Simple API, great deliverability.
  • •
    Hetzner VPS - Cheap, reliable hosting. Application is deployed on a VPS with Coolify.
  • •
    Cloudflare Workers + D1 + R2 - For landing pages, simple databases, and file storage. Fast and very generous free tiers.

Final Thoughts

Building a SaaS is hard. But it's also one of the most rewarding things you can do as a developer because you're forced to learn about things you never did before, not only from an engineering perspective but also from a business perspective. Marketing, sales, support, legal stuff - all the things you used to ignore suddenly matter when it's your product on the line.

Here's the truth that everyone feels when they are starting out: You'll never feel ready to create your SaaS. There's always one more thing to learn - maybe you need to understand databases better, or figure out caching, or finally learn AWS properly. You'll keep postponing because you're not 'prepared enough.'

But here's the thing - it's never been easier to launch a SaaS. All these tools and services I mentioned? They exist so you don't have to be an expert at everything. The technical barriers are mostly gone.

What's left is the hard part: having the courage to ship something imperfect.