Skip to content
Itto Labs
All posts

What it actually takes to ship SaaS solo

The unglamorous parts that decide whether a one-person SaaS survives contact with real users — and how I approach them.

There's a romantic version of building software alone: you, an editor, and pure focus. The real version is mostly about the parts nobody puts on a landing page — the billing edge cases, the migration you can roll back, the webhook that fires twice. Shipping SaaS solo means owning all of it, and being honest about which parts you can't skip.

Here's how I think about it.

Decide what's allowed to be boring

Novelty has a budget. Spend it on the product — the thing your users actually came for — and refuse to spend it on the plumbing. Auth, payments, deploys, and the data model should be as boring and proven as you can make them, because that's where a solo operator gets quietly wrecked.

The corollary: pick tools you can hold the whole shape of in your head. You don't get a platform team to page when something breaks at 2am.

Treat the database as the source of truth

If your permission logic lives in the UI, it isn't real. Push it down to where it can't be bypassed.

-- Row-level security is the enforcement layer, not a suggestion.
create policy "members read their org"
  on documents for select
  using (org_id = auth.org_id());

Doing this from the first migration is dramatically cheaper than retrofitting it after you've shipped. I've paid both prices; the first one is better.

Make webhooks idempotent or don't ship them

Stripe will send you the same event twice. A retry will land while you're still processing the first attempt. If your handler isn't idempotent, you'll corrupt state in ways that are miserable to debug after the fact.

The pattern that has never let me down:

  1. Persist the raw event with its ID before doing anything else.
  2. If you've seen that ID, acknowledge and stop.
  3. Do the work inside a transaction.
  4. Keep a reconciliation job for the drift you didn't predict.

Ship small enough to be wrong cheaply

The fastest way to build the wrong thing is to build a lot of it before anyone uses it. Ship in increments small enough that being wrong costs a day, not a month. The weekly feedback loop is what gets the design right — not how clever the first architecture was.


None of this is glamorous. That's the point. The unglamorous parts are exactly where a solo SaaS lives or dies, and treating them as first-class work is most of the job.