Shipping 20+ micro-SaaS products solo: a playbook

The false choice between shallow and slow

People assume the tradeoff is obvious: build a lot, and each thing is thin. Build one thing well, and you've spent a year on a single bet. I don't think that tradeoff is real — it's what happens when "building a lot" has no process behind it. My catalog currently runs past 20 shipped products, six of which are documented publicly as flagship case studies — Constellation COO, TaskFlow, Scanline, HostGraph, StoreForge, and Autoblog Pipeline — and none of them are 70%-finished demos I'm hoping nobody inspects too closely. That's not because I work faster than other people. It's because I stopped treating each project as a fresh creative act and started treating it as an instance of a process I already trust: scope ruthlessly, build for someone else to run it, measure before you claim it, and manage the portfolio like a portfolio instead of a pile of side projects.

Ruthless scoping: every project starts as a constraint, not an idea

The single biggest lever in this whole playbook is upstream of any code: what I let myself start building in the first place. None of the six flagship assets began as "wouldn't it be cool if." Each one began as a specific, nameable leak — a place where money, time, or reliability was quietly draining out of a real operation, with a shape narrow enough that I could describe the finished product in one sentence before I'd written a line of it.

HostGraph is the clearest example. Restaurant groups don't lose margin at the register — they lose it in the back office, one purchase order and one delivery invoice at a time, in ways individually too small to notice and collectively enormous. That's not "let's build a restaurant dashboard." That's "build the smallest thing that surfaces a margin leak while it's still small," and that framing did most of the scoping work before I opened an editor. It told me which capabilities mattered and, just as important, which adjacent features didn't.

Autoblog Pipeline makes the same point from the opposite angle: instead of a business constraint, I gave myself a hard operating constraint — it had to run for $0 a month, indefinitely, with no human in the loop. That was a requirement from day one, and it did exactly what a tight budget is supposed to do: it eliminated entire categories of "nice" architecture (managed queues, paid inference tiers, a database that needs babysitting) before I could talk myself into them. A constraint you can't negotiate with is a forcing function — the fastest way I know to convert "I could build anything here" into "I can only build this," which is the actual precondition for finishing.

The pattern generalizes: if I can't state the constraint a project relieves in one sentence, I don't have a project yet — I have an idea, and ideas are where scope creep is born. A real constraint has edges. An idea doesn't.

Documentation and tests aren't polish — they're how you leave a project finished

Solo builders tend to treat docs and tests as the thing you add once a project is "done," if you get around to it. I've flipped that: they're part of how the project gets to done at all. Without them, a project doesn't really finish — it just stops, in whatever half-remembered state my brain was in the last time I touched it. Six months later I'm not resuming the project, I'm re-deriving it, and re-deriving your own past decisions is slower than making them the first time.

TaskFlow is the sharpest illustration of what the alternative looks like. It's an autonomous agent framework organized across 30 files with a genuine separation of concerns — planning, execution, verification, memory, and deployment each live in their own space instead of getting tangled into one monolithic loop — and it ships with 36,000 words of documentation covering three separate deployment targets: Vercel, Docker, and a bare VPS. That's not documentation-as-marketing. It's documentation as the thing that lets a framework run somewhere other than my laptop, in front of someone who isn't me and never watched me build it.

The honest version of this principle: I write the docs and tests for future-me as much as for any buyer or collaborator. Future-me, six months and four other projects removed, is functionally a stranger to the decisions present-me is making right now. Tests are the part of the codebase that still tells the truth after I've forgotten why a function is shaped the way it is. Docs are what let me — or anyone else — pick a project back up without a synchronous conversation with the person who built it. "Built for someone else to run it" is item three in how I describe my process, and in practice "someone else" is very often just me, later, having moved on to project fourteen.

Evidence over intuition: don't ship a claim you haven't measured

The fastest way to erode trust in a catalog of 20+ products is to make one performance claim you can't back up. So I hold every project — AI-heavy or not — to the same standard: if I'm going to say something is faster, cheaper, more reliable, or more efficient, I need a benchmark that says so before it goes in a README, not an impression that it probably is.

Constellation COO is where this discipline is most visible, because the whole product is a scheduler and scheduler claims are trivially easy to fake with a good demo and a bad benchmark. I didn't ship the fitness-scored routing approach on the strength of "it feels smarter than round-robin." I benchmarked it against a round-robin baseline under identical synthetic load — same task mix, same pool size, same budget ceiling, repeated trials with bootstrap confidence intervals — before I'd let myself claim anything about SLA compliance or load variance. Only once the numbers held up did the approach become something worth patenting, let alone something worth writing about.

I apply the same instinct to projects that have nothing to do with orchestration. If Scanline claims a digitization workflow is fast, I've timed it. If a dashboard claims it surfaces a margin leak "early," I've checked that against when the leak would otherwise have been caught. The bar isn't "run a rigorous experiment for every feature" — most days that's overkill. The bar is: don't let a number leave your landing page that you invented instead of measured. Intuition is fine for generating a hypothesis. It's a bad place to end the conversation.

Running 20+ products without burning out: batch, decide, don't let anything rot

None of the above works if the operational load of running a catalog this size crushes you inside a year, so the last piece of the playbook is about pace, not code. Three things carry most of the weight.

Batch similar work across projects instead of context-switching per project. Deployment configuration, dependency updates, writing a case study, setting up monitoring — these are the same shape of task whether it's project three or project seventeen, so I do them in batches across several projects at once rather than fully re-entering "project mode" twenty separate times. Context-switching has a real cost, and the way to pay it once instead of twenty times is to group the tasks that share a context, not the tasks that share a deadline.

Every asset is either actively earning or demoable, or it's explicitly shelved — there's no permanent middle state. The most exhausting thing about a large catalog isn't the working products, it's the half-finished ones sitting at "70% done," because a project in that state still costs attention — you still think about it, still feel vaguely guilty about it, still mentally track it as unresolved, without it producing anything. I force a decision on every project: it's finished enough to demo, sell, or run unattended, or I say so out loud and shelve it on purpose. A deliberately shelved project costs nothing. An accidentally-abandoned one costs quiet, ongoing attention for as long as you let it linger.

Solo doesn't mean "no process" — it means the process lives in your head instead of a team's calendar. A team enforces rigor through standups, code review, and a PM asking uncomfortable questions. Working alone, nobody stops you from skipping the docs or shipping an unmeasured claim except you. That's not a reason to have less process — it's a reason the process has to be internalized well enough that you follow it when nobody's watching and there's no external gate forcing you to.

The point isn't productivity — it's that each asset stands on its own

I think about software the way I'd think about real estate: find undervalued ground, build something solid on it, and make it produce. That framing changes what "done" means. A finished asset in this catalog isn't a portfolio piece I point to and say "look what I built" — it's independently valuable on its own terms: sellable, licensable, or demoable to a stranger without me in the room explaining it. StoreForge is explicitly positioned as an acquisition asset for exactly this reason — it has to survive due diligence by someone who has never met me and doesn't take my word for anything.

That's a materially higher bar than "an experiment I got bored of," and it's the bar that makes the whole playbook necessary rather than optional. Ruthless scoping is what makes finishing 20+ things possible. Documentation and tests are what make each one actually finished instead of abandoned. Measuring before claiming is what keeps the catalog's word worth trusting. And treating "shelved" as a real, deliberate state — rather than letting things rot at 70% — is what keeps the operation sustainable for one person. None of it is exotic: it's the last item on the site's stated process, packaging for the next owner, clean history, documentation, data-room readiness, applied not as a final step before a sale but as the standard every project is held to from the day it starts.