Why I’m building five products at once — the honest answer

The version of this post that would perform well on LinkedIn: building multiple products in parallel is a portfolio risk management strategy — diversified bets, shared infrastructure, maximum learning per unit of time.

That’s accurate, yet also incomplete.

The actual reason

I build multiple products simultaneously because I can’t tell in advance which one will find traction, and I’ve made a deliberate choice not to pretend otherwise.

The conventional advice is to go all-in on one thing. Pick the strongest bet, focus entirely on it, give it every available resource. The logic is sound: focus produces better products faster. Splitting attention produces mediocre versions of multiple things.

The problem with that logic, in my specific situation, is that it assumes I know which bet is strongest before I’ve tested any of them. I don’t. The products are solving different problems for different markets. Some of those markets are ones I understand well. Others I understand directionally but not deeply. My confidence in any individual product’s viability is real but bounded.

Running five products in parallel isn’t a failure of focus. It’s a response to genuine uncertainty about where the signal will come from.

What makes it possible

This approach only works because of the infrastructure underneath it. SR-SI means each product has a maintained context index that an AI agent can read at the start of any session. I’m not re-orienting myself to five different codebases from scratch every time I switch. The documentation does the re-orientation.

The result is that I can build across five products without the context-switching cost that would normally make this unsustainable. Each product has its own index, its own documented decisions, its own architectural record. I show up to build, the index tells the AI what exists, and we proceed from there.

Without that infrastructure, building five products simultaneously would produce exactly what the critics predict: five mediocre half-built things and one very tired developer.

The honest cost

What it actually costs is attention depth. When you’re focused on one product, you can hold every edge case, every user scenario, every design constraint in working memory simultaneously. When you’re splitting across five, you can’t. You rely more heavily on documentation. You make slightly slower decisions because you need to re-read context you would otherwise carry in your head.

That’s a real tradeoff. I’ve accepted it in exchange for the diversification — the ability to kill something that isn’t working without it being an existential decision, and to pursue signal wherever it appears rather than betting everything on a single read of the market.

The kill criteria

Pre-committed and non-negotiable: three months post-launch with no paying customers means the product is terminated. Not pivoted, not repriced, not given one more month. Terminated.

This constraint is what makes the parallel build strategy honest rather than self-indulgent. Without it, running multiple products becomes a way of avoiding the accountability that comes with going all-in on one. With it, each product has a clear test and a clear exit condition. The portfolio isn’t infinite. It’s five concurrent experiments, each with a defined end state.

Gestalt launched February 4. Protocol launched March 1. The clocks are running.

View all active products