I am currently building five products in the open: InstantPlan (AI floor plans for loan agents), AllOS (a self operating system for life), BankGaadi (a vehicle-auction aggregator), RecoverOS (an AI posture coach), and Viksepa (a screen-addiction minimizer for kids). People assume the hard part is the code. It is not. The hard part is the operating system that keeps five 0-to-1 products moving without any of them rotting.
Building in public is a product strategy
Building in public is usually framed as marketing — post your progress, grow an audience. That is the smallest benefit. The real value is forced clarity and faster feedback. When you commit to shipping in the open, you cannot hide behind a six-month stealth build. You ship the narrowest thing that proves the idea, you get a real reaction, and you adjust. It is the validate-fast principle with social accountability bolted on.
Rule 1: every product gets a written spec before code
It is tempting, solo, to just start typing. I do the opposite. AllOS had 16 PRDs locked before a line of product code. That sounds heavy for a solo build — it is the opposite. The spec is what lets me context-switch between five products without re-deriving every decision each time I open a repo. The document is the memory.
Rule 2: one riskiest-assumption per product at a time
Five products do not mean five full roadmaps. Each product has exactly one live question — the riskiest assumption that, if false, kills it. InstantPlan: will loan agents trust an AI-generated plan enough to attach it to a bank file? BankGaadi: can scrapers stay ahead of a dozen portals changing formats? I build only what tests that question. Everything else waits.
Rule 3: reuse the stack, vary the problem
The products look different but the stack rhymes: Next.js, a Postgres or Supabase data layer, an LLM provider, Vercel. RecoverOS and Viksepa diverge (a Chrome extension and an Android app) because their problems demand it, not because I wanted variety. Reusing the stack means a lesson learned on one product transfers to the next for free. The variety is in the problems, not the tools.
Rule 4: ship the embarrassing version
Every one of these went live or to private beta before it was "ready." InstantPlan generated rougher plans at first. That is the point. A live rough version teaches you more in a week than a polished private one teaches you in a quarter, because real users do things your spec never imagined.
Rule 5: kill criteria, written down
Building in public makes you emotionally attached because the audience is watching. So I write the kill criterion for each product in advance: the condition under which I stop. It removes ego from the decision. A product that has not cleared its riskiest assumption by its date gets shelved, publicly, without drama.
What it adds up to
Building in public is not about the audience. It is a discipline that forces narrow scope, fast feedback, honest kill decisions, and reusable infrastructure. Do it for the clarity. The audience is a side effect.