Isn't running multiple products worse than focusing on one?

For a venture-backed company chasing one huge market, yes — focus wins. For a solo operator, a small portfolio spreads risk and smooths revenue: when one product is quiet, another is growing. The constraint is that every product must be operable in a couple of hours a week once it's live, which forces you to build boring, reliable software instead of fragile, clever software.

How do you handle support for four products alone?

By making support rare by design. Most tickets come from onboarding confusion and billing edge cases, so we over-invest in both once and stop paying that tax forever. Everything else routes to one inbox, and anything that generates a second identical ticket becomes a docs fix or a product fix that day.

What's the one thing that makes a solo portfolio possible?

A shared foundation. All four products stand on the same boilerplate, the same deploy pipeline, and the same operational habits, so the marginal cost of the fourth product is a fraction of the first. Without that shared base, four products would be four times the work; with it, it's closer to one-and-a-half.

How One Person Runs Four Software Products

I build and operate four live products by myself: Inchworm, an iOS app for starting things; Propelr, which writes social posts in your own voice; RedNudge, which watches Reddit for you; and SaaSInMinutes, a boilerplate other founders launch on. People assume this means I’m drowning. Mostly I’m not, and the reason is boring: the products share a foundation, and I refuse to build anything I can’t operate in a couple of hours a week.

Here’s how it actually works.

One foundation under everything

The first product is expensive. You wire up authentication, payments, transactional email, error tracking, an admin panel, and a deploy pipeline before you’ve written a line of the thing anyone actually wants. That’s roughly forty hours of undifferentiated plumbing.

You pay that once. SaaSInMinutes exists because I got tired of paying it repeatedly — it’s the exact foundation the other products stand on, packaged so other founders can skip the forty hours too. Every product uses the same auth flow, the same payment webhooks, the same monitoring, the same one-command deploy. When I fix a bug in the foundation, four products get the fix.

This is the whole trick. A portfolio isn’t four times the work when the products aren’t four separate things — they’re four surfaces on one shared base.

Every product has to be boring to operate

There’s a difference between software that’s impressive to build and software that’s cheap to run. Solo, you can only afford the second kind.

Before I ship anything, I ask one question: what will this page me about at 2am? If the answer is “a background job that silently falls behind,” I redesign it until the answer is “nothing.” That usually means fewer moving parts, idempotent jobs that can be safely re-run, and defaulting to email digests over real-time systems that have to be right every second.

RedNudge is a good example. It scans Reddit every thirty minutes, scores matches with Claude, and emails a daily digest. The tempting version is a real-time dashboard that updates live. The operable version is a batch job and an email. The email version is the one a single person can run for years without it becoming a second job.

Make support rare, not fast

You cannot out-work support for four products by answering tickets quickly. You have to make tickets not happen.

Almost every ticket comes from two places: onboarding confusion and billing edge cases. So those two things get disproportionate attention exactly once. Onboarding gets tested until a stranger can complete it without me. Billing gets the customer portal, the webhooks, and the dunning emails wired properly so I’m not manually fixing subscriptions.

Everything after that follows one rule: the second identical ticket is a bug. The first time someone asks a question, I answer it. The second time, I fix the product or the docs so a third person never asks. Support that compounds downward instead of upward is the only kind that scales to one person.

What a normal week looks like

A week operating four products

Not a rigid schedule — a rough allocation that keeps four live products healthy without a team.

Triage once, in the morning
One inbox for all four products. Anything urgent gets handled; anything recurring gets logged as a fix. Fifteen minutes, most days.
One product gets real attention
Each week, exactly one product gets feature work or a marketing push. The other three are in maintenance. Rotating focus beats splitting attention four ways every day.
Ship small, deploy often
Small changes through the same CI/CD pipeline for every product. Small deploys are reversible deploys, which is what lets one person move fast without a safety net of teammates.
Write the thing down
Every fix, decision, and gotcha goes into the repo. Your future self is the teammate you actually have, and documentation is how you talk to them.

The rotation matters more than it sounds. Trying to move all four products forward every day is how you move none of them forward and feel busy doing it. One product in focus, three in maintenance, rotate weekly. Over a month, everything gets attention; in any given week, one thing gets progress.

The honest trade-offs

This isn’t free. A portfolio means no single product gets the undivided obsession that a focused startup gives its one bet. If one of these were a rocket ship, splitting my attention would be leaving money on the table, and I’d cut the others.

But that’s exactly the bet: I don’t know which one is the rocket ship, and a portfolio lets the market tell me instead of me guessing. When one product is quiet, another is usually growing. The revenue is smoother, the risk is spread, and the shared foundation means the cost of being wrong about any single product is low.

Focus is the right advice for most companies. For a solo builder who wants to stay solo, a small, well-operated portfolio on a shared foundation is a different game with different rules — and those rules are the whole reason it’s possible at all.

If you’re assembling your own foundation, the build-or-buy question is worth settling deliberately rather than by default — we compared what the boilerplates actually cost and include, ours among them.

Frequently asked questions

Isn't running multiple products worse than focusing on one?: For a venture-backed company chasing one huge market, yes — focus wins. For a solo operator, a small portfolio spreads risk and smooths revenue: when one product is quiet, another is growing. The constraint is that every product must be operable in a couple of hours a week once it's live, which forces you to build boring, reliable software instead of fragile, clever software.
How do you handle support for four products alone?: By making support rare by design. Most tickets come from onboarding confusion and billing edge cases, so we over-invest in both once and stop paying that tax forever. Everything else routes to one inbox, and anything that generates a second identical ticket becomes a docs fix or a product fix that day.
What's the one thing that makes a solo portfolio possible?: A shared foundation. All four products stand on the same boilerplate, the same deploy pipeline, and the same operational habits, so the marginal cost of the fourth product is a fraction of the first. Without that shared base, four products would be four times the work; with it, it's closer to one-and-a-half.