What is a product factory?

A product factory is not a boilerplate. It's an operating system. FactoryStarter is built on three observations about indie SaaS in 2026 — and this page is the long version of why those observations change everything from pricing to kill decisions.

The single-product trap

The default indie SaaS playbook is single-product: pick an idea, build for months, launch, hope. The math is brutal — most products don't hit meaningful revenue, so the “one big bet” strategy is statistically the worst version of the indie life. You spend twelve months on a coin flip.

Worse, the single-product mindset infects everything else. You over-invest in features that don't move the needle, you delay launching because “it's not ready,” and when the product fails you start the next one from a blank repo. Six months of plumbing, again, just to get to feature work.

The portfolio insight

Portfolio thinking inverts the math. If 1 in 20 products hits, then your job is not to make any single product succeed — your job is to ship enough at-bats to give one a chance. That means optimizing the system, not the product. The unit of work moves from “feature” to “product.”

In a portfolio model, the boilerplate is the load-bearing artifact. Every hour saved on plumbing across N products compounds. Every kill rule applied consistently across the portfolio prevents you from rotting on dead products. Every shared component (auth, payments, deploy, monitoring) is amortized N times. The factory is the lever.

What “factory” means concretely

FactoryStarter ships seven things that, together, make a portfolio operable by one person:

Repeatable scaffolding. A single command (new-product.sh) bootstraps product N+1 with 186 files of opinionated infrastructure. Auth, payments, RLS, CI, deploy — done.
Specialized AI agents. Ten Claude Code agents with explicit responsibilities (spec-writer, designer, senior-dev, tester, reviewer, devops, tech-writer, marketer, support-bot, analyst). Each one is a system prompt with hand-off contracts to the next agent. You don't re-teach Claude what kind of work this is.
Persistence between sessions. Every product has a STATE.md that the agents read on startup and update at the end of each turn. This is the difference between Claude as a tool and Claude as a teammate.
Background monitoring. Five cron-driven agents that watch the portfolio without you: kill-monitor, analyst, seo-checker, pr-reviewer, dependency-bot. They surface problems; you decide.
Playbooks for recurring decisions.Eight playbooks (ship-day, distribution, pricing-iteration, kill-or-scale, customer-support, …) so you don't re-invent the process every time.
Kill rules. The hardest part of a portfolio: knowing when to stop. FactoryStarter encodes thresholds so products that don't reach traction get sunset on a schedule, not on emotion.
A shared learning surface. Every product's BUILD_REPORT and post-launch analysis feeds back into the playbooks. The factory gets smarter every cycle.

The math behind 60 products in 6 months

60 products / 6 months = 10 products per month, ~2.5 per week. Impossible with a single-product workflow; tractable with a factory. The reason: each product reuses ~80% of the work — the boilerplate, the agents, the deploy pipeline, the playbooks. The 20% that's product-specific is the actual feature work, which is also where Claude Code earns its keep.

At a 5% hit rate (1 in 20), 60 products yields 3 winners. At a 10% hit rate, 6 winners. Either way, a portfolio outperforms a single product on expected value and on resilience to bad luck.

Why this needs to be a system, not a process

Process documents rot. Notion pages get out of date by week two. The only way a factory survives contact with reality is to encode it in code: in CI workflows that run on every PR, in agent system prompts that the model reads on every session, in templates that scaffold the next product, and in cron jobs that monitor the portfolio without supervision.

That's why FactoryStarter is a repo and not a course. Courses get bookmarked; repos get cloned and run.

When NOT to use a factory

If you have a single product idea you're emotionally certain about and you're willing to spend 12 months on it, a factory is overkill — go buy ShipFast and ship that one thing. Factories are for builders who've felt the pain of starting over and want a system that compounds.

Want to read the technical decisions next? See The factory stack and decisions.