How do you build multiple products at once without losing focus?

With a repeatable operating system rather than fresh improvisation each time: I only build from real recurring problems I've actually hit, I define the outcome before I design a single screen, I use AI to move fast on execution while keeping the product decisions human, I ship on one solo-friendly stack so nothing is bespoke, and I apply explicit kill criteria so weak experiments die quickly. The system is what lets several small products coexist without any one of them consuming all the attention.

What is a product operating system?

It's the small set of repeatable rules and steps you run every time you take an idea to a shipped product — how you choose what to build, how you define success before building, how you make decisions, what stack you use, and how you decide when to stop. For a solo builder shipping multiple products, it replaces per-project improvisation with a consistent process, which is what makes building several things at once sustainable instead of chaotic.

My Product Operating System for Building Multiple AI Apps

Q: Should a solo founder use AI to build products?

Yes, for leverage — but with a hard line. AI is exceptional at execution: scaffolding, code, boilerplate, first drafts, moving fast. It should not make the product decisions — what problem to solve, what the outcome is, what to cut, what to charge. Used as a fast executor under human product judgment, AI lets one person ship what used to take a team; used as the decider, it produces polished apps that solve nothing in particular.

The usual advice for a solo builder is to focus — pick one product and pour everything into it. That's the textbook answer, and it holds right up until you have a second problem worth solving. The version I've earned runs several focused products at once, and it comes down to five rules: build only from real recurring problems, define the outcome before the screen, use AI to execute but never to decide, ship on one solo-friendly stack, and kill weak experiments fast. Building one product is a project. Building several without drowning is a system. Without one, every new idea restarts from zero and the attention spreads until nothing ships. This is the system I run — grounded less in indie-hacker theory than in eighteen years of watching enterprise programmes succeed or fail on exactly these disciplines.

1. Build only from real, recurring problems

I don't build ideas. I build problems I've personally hit more than once. Every product I've shipped started as a recurring friction in real work — a leadership ask that kept landing on my desk unshaped, a local recommendation I kept losing track of. The test is simple: have I met this problem repeatedly, and did I wish something existed? If the honest answer is no, it's a clever idea, not a product — and clever ideas are where solo builders go to lose months.

This is the biggest filter of the five, because the cost of building the wrong thing is the same whether you're a team or one person. You just feel it more alone.

2. Define the outcome before the screen

Before I design a single screen, I write down what will be true for the user when the product works — the outcome, not the interface. It's the discipline I built Delivery Sheet on: the expected result comes first, and the screen is just the route to it. Design the screen first and you fall for a UI before you know its job. Define the outcome first and the screen almost designs itself, because now it has one.

If I can't state that outcome in one sentence a user would recognize, the idea isn't ready to build.

3. Use AI to execute, never to decide

AI is the reason one person can now ship what used to take a team — but only if you hold a hard line on what it's for. I lean on it heavily for execution: scaffolding, code, boilerplate, first drafts, moving fast. I do not let it make the product decisions — what problem to solve, what the outcome is, what to cut, what to charge. Those stay mine.

The reason most AI-built apps feel like demos is that AI made the product calls, and AI optimizes for plausible, not pointed. Keep it as the fast hands and yourself as the judgment, and you get the leverage without losing the thing that makes a product actually solve something.

4. Ship on one solo-friendly stack

Every product runs on the same stack — Nuxt and Supabase — on purpose. A consistent stack means nothing is bespoke: what I learn on one product carries to the next, the deployment is identical, the mental model doesn't reset. Sameness is speed. The moment each product grows its own special architecture, a portfolio turns into a maintenance load no single person can hold. Boring, repeated infrastructure is what frees the attention for the part that's genuinely different — the problem.

5. Kill weak experiments fast

The hardest rule, and the one that makes multiple products possible: explicit kill criteria, decided before I get attached. An experiment that isn't earning its attention — no signal, no pull, no path to mattering — should die quickly and cleanly, so the attention moves to what's working. Solo, you can't afford a graveyard of half-tended products quietly draining focus. Deciding in advance what "not working" looks like is what lets you let go without re-litigating it every time.

The five rules at a glance

Each rule exists to stop one specific, expensive failure. Read down the last column and you're reading the list of ways solo product-building actually goes wrong.

Rule	What it filters out	The failure it prevents
Build from real, recurring problems	Clever ideas you haven't personally lived	Months lost building the wrong thing
Define the outcome before the screen	UIs that have no job yet	Aimless design; falling for an interface first
AI executes, never decides	AI's plausible-average product calls	Polished demos that solve nothing
One solo-friendly stack	Bespoke per-product architecture	A maintenance load one person can't hold
Kill weak experiments fast	Attention-draining half-products	A graveyard that quietly starves what's working

Why it's a system, not a vibe

Any one of these on its own is just a decent instinct. Run all five, every time, and they become the thing that makes several focused products sustainable for one person: the problem filter stops wasted builds, the outcome-first rule stops aimless UIs, the AI line keeps the products pointed, the shared stack keeps the whole thing maintainable, and the kill criteria keep the attention where it earns its keep. It's the same truth I learned in enterprise delivery — outcomes over activity, decisions made on purpose — applied to a studio of small products instead of one big programme.

Part of Building AI Products. See also how I use AI without letting AI make product decisions and why I write the expected output before the screen. The newsletter sends one practical build lesson every two weeks.