Scaling as a Solo Dev

Building a SaaS product by yourself is hard. Scaling it is harder. And scaling it while still answering support emails, pushing bugfixes, and writing your next blog post? That’s borderline heroic.

But don’t panic. You don’t need to reinvent how the internet works. You just need a few good patterns - and a plan.

What Does “Scaling” Actually Mean?

Let’s clear something up: scaling isn’t just about surviving a “Hacker News hug of death.”

It’s also:

• When your database starts getting slow because it’s no longer tiny
• When you go from one Stripe customer to a hundred, and suddenly need to automate refunds
• When you’re getting support emails daily, and it’s interrupting your dev flow
• When you’re not sure what to prioritize next, because people are actually using your thing now

Scaling is partly technical, yes - but it’s also organizational. It’s about how you handle growth, pressure, and complexity.

Scaling Up vs Scaling Out

At some point, your app will hit limits. Maybe it’s the database. Maybe your API responses slow to a crawl. When that happens, you’ve got two main options:

Scaling Up (Vertical Scaling)

This means throwing more resources at the same machine.

• Move from a 2GB to 8GB VPS
• Upgrade your Supabase plan
• Swap your SQLite DB for Postgres

Pros:

• Simple - you often don’t need to change your code
• Fast - you can usually scale up in minutes

Cons:

• There’s a ceiling - you’ll eventually max out
• Can get expensive fast

Scaling Out (Horizontal Scaling)

This means adding more machines to share the load.

• Add more frontend edge nodes (handled for you by Cloudflare)
• Spin up background worker instances for async jobs
• Use read replicas on your database

Pros:

• Much higher potential for scale
• More resilient (one node can go down and things still work)

Cons:

• More complexity - load balancers, state syncing, etc
• Might require code changes (e.g. stateless architecture)

The “What If My App Goes Viral?” Plan

Most apps won’t go viral. But if yours does - even a little - it can break in surprising ways.

Here’s a checklist to stay sane:

• CDN first. Put your frontend behind something like Cloudflare Pages or Netlify. They scale automatically.
• Supabase for backend. Their Postgres database, Edge Functions, and auth are production-ready from day one. The free tier isn’t a toy - it’s robust.
• Monitor everything. Set up logging (like Supabase’s built-in), error reporting (Sentry or Highlight.io), and uptime checks (UptimeKuma, or even GitHub Actions + curl).
• Rate limiting and abuse protection. Use middleware to throttle requests. If someone floods your /api/signup, your Stripe bill will hurt.
• Queue async work. Anything slow (email, image processing, webhook calls) should go into a queue. Supabase has background functions, or you can spin up a cheap VPS and run bullmq or pg-boss.

Maturity Milestones for Growth

Most apps don’t go viral. They grow slowly. Which is actually…better. Here’s a loose progression of what scaling looks like in real life:

Level I: Launch & First Users

• Frontend: Cloudflare Pages or Netlify
• Backend: Supabase on free or hobby plan
• Email: Postmark or Resend for transactional emails
• Payments: Stripe with manual review for edge cases
• Logging: Supabase Logs or simple console logs + Logflare
• Support: Personal email inbox, or support@ forwarded to you

Level II: Dozens of Paying Users

• Add telemetry (PostHog, Plausible) to see real usage
• Add uptime monitoring (UptimeKuma, Cronitor)
• Use GitHub Actions or cron jobs for regular jobs
• Begin keeping changelogs and upgrade notes
• Start writing documentation you don’t hate

Level III: Hundreds of Users

• Upgrade Supabase tier
• Add queueing layer (Supabase Edge functions + Deno KV, or an external worker)
• Move secrets to a proper secret store (Doppler, Cloudflare Secrets, etc)
• Use status page (e.g. Upptime, BetterStack) to show uptime
• Consider light observability tooling (Highlight.io, Sentry, SigNoz)

Marketing and Growth - The Other Scaling

Once you’ve handled the tech side, you’ll start asking: “How do I scale attention?”

Here are some ways that don’t require being a sales bro:

• Write a blog post about each new feature. Use it to teach, not just promote.
• Set up an onboarding email sequence. Drip helpful tips, not hype.
• Re-share your launch post every few months. No one saw it the first time.
• Join niche forums or Discords. Help people. Link your project only when relevant.
• Partner with someone who lives for marketing. You don’t have to do this alone. See Finding Founders.

What Happens When You Can’t Do It Alone?

There’s a point where brute force stops working. Here are signs you need help:

• Support requests are eating your weekends
• Marketing feels like guesswork and stress
• You’re terrified to push a new release
• You’ve hit a skills ceiling (e.g. SEO, legal, scaling infra)

This is when it’s time to:

• Bring on a part-time contractor (support, design, QA)
• Automate everything you do twice
• Document your internal processes
• Consider finding a cofounder with strengths you lack

Summary

Scaling as a solo dev isn’t just possible - it’s manageable with the right stack and a steady mindset. You don’t need a 10x engineer or a million-dollar budget.

You need:

• A simple, scalable tech stack (like Supabase + Cloudflare)
• Clear priorities and lightweight automation
• A willingness to grow - both your app and yourself

Let’s not overthink it. Build something useful. Ship it. Grow slowly. Iterate. And bring in help when you need it.