[{"data":1,"prerenderedAt":290},["ShallowReactive",2],{"blog-\u002Fblog\u002Fmy-product-operating-system":3,"blog-surround-\u002Fblog\u002Fmy-product-operating-system":270,"blog-related-\u002Fblog\u002Fmy-product-operating-system":279},{"id":4,"title":5,"audience":6,"body":10,"cluster":235,"date":236,"description":237,"draft":238,"extension":239,"factCheckedAt":240,"faq":241,"featured":238,"language":240,"meta":251,"navigation":252,"order":253,"originalAsset":240,"path":254,"pillar":255,"primaryKeyword":256,"relatedProject":240,"releaseScope":240,"reviewCycle":257,"reviewStatus":258,"reviewedBy":259,"searchIntent":260,"seo":261,"sources":240,"stem":262,"tags":263,"type":267,"updated":268,"__hash__":269},"blog\u002Fblog\u002Fmy-product-operating-system.md","My Product Operating System for Building Multiple AI Apps",[7,8,9],"indie-founder","solo-developer","product-builder",{"type":11,"value":12,"toc":224},"minimark",[13,27,32,35,38,42,50,53,57,64,72,76,84,88,95,99,102,183,187,195,198],[14,15,16,20,21,26],"p",{},[17,18,19],"strong",{},"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 ",[22,23,25],"a",{"href":24},"\u002Fblog\u002Fhow-i-stay-sane-building-products-solo","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.",[28,29,31],"h2",{"id":30},"_1-build-only-from-real-recurring-problems","1. Build only from real, recurring problems",[14,33,34],{},"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.",[14,36,37],{},"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.",[28,39,41],{"id":40},"_2-define-the-outcome-before-the-screen","2. Define the outcome before the screen",[14,43,44,45,49],{},"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 ",[22,46,48],{"href":47},"\u002Fproducts\u002Fdelivery-sheet","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.",[14,51,52],{},"If I can't state that outcome in one sentence a user would recognize, the idea isn't ready to build.",[28,54,56],{"id":55},"_3-use-ai-to-execute-never-to-decide","3. Use AI to execute, never to decide",[14,58,59,60,63],{},"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 ",[17,61,62],{},"not"," let it make the product decisions — what problem to solve, what the outcome is, what to cut, what to charge. Those stay mine.",[14,65,66,67,71],{},"The reason ",[22,68,70],{"href":69},"\u002Fblog\u002Fwhy-most-ai-built-apps-feel-like-demos","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.",[28,73,75],{"id":74},"_4-ship-on-one-solo-friendly-stack","4. Ship on one solo-friendly stack",[14,77,78,79,83],{},"Every product runs on the ",[22,80,82],{"href":81},"\u002Fblog\u002Fnuxt-and-supabase-solo-saas-stack","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.",[28,85,87],{"id":86},"_5-kill-weak-experiments-fast","5. Kill weak experiments fast",[14,89,90,91,94],{},"The hardest rule, and the one that makes multiple products possible: ",[17,92,93],{},"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.",[28,96,98],{"id":97},"the-five-rules-at-a-glance","The five rules at a glance",[14,100,101],{},"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.",[103,104,105,121],"table",{},[106,107,108],"thead",{},[109,110,111,115,118],"tr",{},[112,113,114],"th",{},"Rule",[112,116,117],{},"What it filters out",[112,119,120],{},"The failure it prevents",[122,123,124,136,147,161,172],"tbody",{},[109,125,126,130,133],{},[127,128,129],"td",{},"Build from real, recurring problems",[127,131,132],{},"Clever ideas you haven't personally lived",[127,134,135],{},"Months lost building the wrong thing",[109,137,138,141,144],{},[127,139,140],{},"Define the outcome before the screen",[127,142,143],{},"UIs that have no job yet",[127,145,146],{},"Aimless design; falling for an interface first",[109,148,149,152,155],{},[127,150,151],{},"AI executes, never decides",[127,153,154],{},"AI's plausible-average product calls",[127,156,157,158],{},"Polished ",[22,159,160],{"href":69},"demos that solve nothing",[109,162,163,166,169],{},[127,164,165],{},"One solo-friendly stack",[127,167,168],{},"Bespoke per-product architecture",[127,170,171],{},"A maintenance load one person can't hold",[109,173,174,177,180],{},[127,175,176],{},"Kill weak experiments fast",[127,178,179],{},"Attention-draining half-products",[127,181,182],{},"A graveyard that quietly starves what's working",[28,184,186],{"id":185},"why-its-a-system-not-a-vibe","Why it's a system, not a vibe",[14,188,189,190,194],{},"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 — ",[22,191,193],{"href":192},"\u002Fblog\u002Fhow-to-define-a-measurable-outcome","outcomes over activity",", decisions made on purpose — applied to a studio of small products instead of one big programme.",[196,197],"hr",{},[14,199,200],{},[201,202,203,204,208,209,213,214,218,219,223],"em",{},"Part of ",[22,205,207],{"href":206},"\u002Ftopics\u002Fbuilding-ai-products","Building AI Products",". See also ",[22,210,212],{"href":211},"\u002Fblog\u002Fhow-i-use-ai-without-letting-ai-decide","how I use AI without letting AI make product decisions"," and ",[22,215,217],{"href":216},"\u002Fblog\u002Fwhy-i-write-the-expected-output-before-the-screen","why I write the expected output before the screen",". The ",[22,220,222],{"href":221},"\u002Fnewsletter","newsletter"," sends one practical build lesson every two weeks.",{"title":225,"searchDepth":226,"depth":226,"links":227},"",2,[228,229,230,231,232,233,234],{"id":30,"depth":226,"text":31},{"id":40,"depth":226,"text":41},{"id":55,"depth":226,"text":56},{"id":74,"depth":226,"text":75},{"id":86,"depth":226,"text":87},{"id":97,"depth":226,"text":98},{"id":185,"depth":226,"text":186},"process","2026-07-24","The product operating system I use to build several focused AI products solo: choosing which problem to build, shipping fast, and killing what isn't working.",false,"md",null,[242,245,248],{"question":243,"answer":244},"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.",{"question":246,"answer":247},"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.",{"question":249,"answer":250},"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.",{},true,1,"\u002Fblog\u002Fmy-product-operating-system","building-ai-products","product operating system","annual","reviewed","Tan Gravam","informational",{"title":5,"description":237},"blog\u002Fmy-product-operating-system",[255,264,265,266,235],"product","solo-saas","ai","text","2026-07-26","d8fzZqYCqv22mm7hZZVC8a8qZoeIfaXKfbtYBizS9-A",[271,275],{"title":272,"path":273,"stem":274,"type":267,"language":240,"draft":238,"children":-1},"My Kill Criteria for Product Experiments","\u002Fblog\u002Fmy-kill-criteria-for-product-experiments","blog\u002Fmy-kill-criteria-for-product-experiments",{"title":276,"path":277,"stem":278,"type":267,"language":240,"draft":238,"children":-1},"Natural Hedging vs Financial Hedging","\u002Fblog\u002Fnatural-hedging-vs-financial-hedging","blog\u002Fnatural-hedging-vs-financial-hedging",[280,284,287],{"path":281,"title":282,"description":283},"\u002Fblog\u002Fhow-i-decide-whether-an-ai-product-idea-is-worth-building","How I Decide Whether an AI Product Idea Is Worth Building","How to decide what product to build: the short filter I run every idea through — real recurring problem, one-sentence outcome, small enough to ship solo.",{"path":216,"title":285,"description":286},"Why I Write the Expected Output Before the Screen","Define the outcome before design: I write the exact result the user should get before building any screen, because the screen is only the path to an outcome.",{"path":211,"title":288,"description":289},"How I Use AI Without Letting AI Make Product Decisions","Using AI to build products means AI owns the how — code, scaffolding, drafts — while I keep the what and why: the problem, outcome, cuts and pricing.",1785182341859]