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 repeatable system I use to build several focused AI products solo 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 operating system I run — grounded less in indie-hacker theory than in 18 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 arriving unshaped, a local recommendation I kept losing. 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 waste months.

This is the single biggest filter, because the cost of building the wrong thing is the same whether you're a team or a 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 same discipline I put into Delivery Sheet: the expected result comes first, and the screen is just how you get there. Design the screen first and you fall in love with a UI before you know what it's for; define the outcome first and the screen almost designs itself, because now it has a job.

If I can't state the 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 need a team — but only if you hold a hard line about what it's for. I use AI 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 human.

The reason most AI-built apps feel like demos is that AI made the product decisions, and AI optimizes for plausible, not pointed. Keep AI as the fast hands and yourself as the judgment, and you get 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 — deliberately. A consistent stack means nothing is bespoke: what I learn on one product transfers to the next, the deployment is the same, the mental model is the same. For a solo builder, sameness is speed. The moment each product has its own special architecture, you've turned a portfolio into a maintenance burden that no one person can hold. Boring, repeated infrastructure is what frees the attention for the part that's actually different — the problem.

5. Kill weak experiments fast

The hardest discipline, 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 goes to what's working. Solo, you can't afford a graveyard of half-tended products draining focus. Deciding in advance what "not working" looks like is what lets you let go without agonizing each time.

Why it's a system, not a vibe

Any one of these as a one-off is just a good instinct. Together, run every time, they're what make building 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.