How I keep the system simple while building several products alone
A multi-product portfolio creates unavoidable complexity. The goal is not to remove it, but to stop repeating decisions, switching tools and keeping every product mentally active at the same time.
The attractive part of a product portfolio is variety. The expensive part is context. Every product has its own backlog, bugs, domain, deployment, billing and mental model.
To run more products, I need to make fewer repeated decisions.
Do not make every project a separate universe
I no longer force every product onto the same stack, but I keep strong defaults. An exception needs a product reason, not curiosity.
const defaults = { sourceOfTruth: "GitHub", frontend: "React + TypeScript when appropriate", deploy: "Cloudflare when it fits", backend: "Supabase unless product needs justify another choice", release: "explicit production gate",};One source of truth is non-negotiable
With agent worktrees, previews, local branches and production deployments, several versions of reality can exist. For code, GitHub is my source of truth. Local success is not completion until the canonical repository and deployed commit agree.
Portfolio and active workload are different things
Owning five products does not mean actively developing five products. I use explicit product states to protect attention.
type ProductState = | "primary" | "active-secondary" | "maintenance" | "experiment" | "paused";Without a priority order, novelty wins
New ideas are cleaner and more exciting than existing bugs. A predefined product order prevents the newest idea from silently becoming the roadmap.
Standardize decisions before code
I prefer to standardize release principles, repo verification, SEO checks and agent protocols before extracting shared packages. Premature shared code can become another platform project.
AI makes portfolio discipline more important
AI reduced the cost of starting a product. It did not reduce the cost of maintaining one. As build cost falls, the question changes from “can I build this?” to “do I want to carry this for a year?”
const productCost = buildCost + hostingCost + supportCost + maintenanceCost + attentionCost;Explicit release gates protect a portfolio
I automate cheap verification but keep deliberate gates around migrations, store builds and critical production releases. In a multi-repo environment, a little friction can be a control layer.
const automationPolicy = { lint: "automatic", test: "automatic", databaseMigration: "explicit", storeRelease: "explicit",};New tools are guilty until useful
Every extra analytics service, deployment panel or workflow increases the address space I must remember. A new tool should remove measured friction, not simply be more interesting.
I do not merge every backlog
Products keep their own context, but one portfolio decision chooses which context gets attention this week.
type WeeklyPortfolioDecision = { primaryProduct: string; primaryOutcome: string; secondaryMaintenance: string[]; explicitlyNotDoing: string[];};Products need an exit state
A failed or weak experiment should be allowed to pause. Otherwise a portfolio only accumulates maintenance. Returning attention to a stronger product is a capital-allocation decision.
My compact operating system
- One clear primary product
- Explicit states for everything else
- GitHub as code truth
- Shared defaults with justified exceptions
- Human gates for risky releases
- Maintenance cost included before starting
- A weekly not-doing list
Conclusion
Modern tools make it possible for one person to operate several products. They do not make attention infinite. My system exists to protect that finite resource.
const soloPortfolio = { ideas: "many", activePriorities: "few", sourceOfTruth: "one", exceptions: "expensive", attention: "finite",};