On Building Solo

Every additional person on a project adds coordination cost that no burndown chart captures. Alignment meetings, handoff documents, review queues, context switching between mental models — this is the invisible tax of teamwork, and it compounds faster than output does.

Building solo is not a sacrifice of scale. Done deliberately, it is the removal of that tax. The question stops being "how do we keep everyone in sync" and becomes "how do I make the system self-evident."

The failure mode of AI-assisted development is treating the model like a junior engineer: assign vague tasks, review outputs, correct course. That model caps your throughput at your own review bandwidth — which is to say, it changes nothing.

The better frame is co-founder: give the model ownership of bounded domains with explicit contracts. It drafts the migration, you ratify the schema. It generates the test matrix, you define the invariants. Authority flows through interfaces, not supervision.

A solo operator cannot rely on teammates to catch what they miss, so the system itself must do the catching. CI gates, static analysis, typed boundaries, automated deploys with instant rollback — every safeguard a senior team would provide socially must be built structurally.

The paradox resolves cleanly: the discipline that makes solo viable is the same discipline that makes any codebase good. Solo just removes the option of skipping it.

The honest cost of building alone is not workload — automation handles that. It is epistemic isolation. No one challenges your assumptions unless you build mechanisms that do: ruthless user feedback loops, public artifacts, adversarial reviews of your own designs.

Leverage without feedback is just speed in the wrong direction. Build the loop before you need it.