Six products, one founder: how I prevent context collapse

Over the last year, I wrote more code than during the rest of my life combined.

I also wrote and released a full book.

That sounds like the usual founder productivity bullshit. It is not. I did not discover a better morning routine, stop sleeping, or learn to type faster.

AI changed how much engineering work one person can direct.

I am now building six products. Before AI, I could maybe have built one of them alone, with my full attention. Most would have required a team of engineers.

So why am I working on six at the same time?

Because I can.

That is the leverage AI created. The difficult part is no longer producing enough code. It is keeping enough context to direct the work without getting lost.

What six products actually means

At the time of writing, the portfolio looks like this:

NodiumLabs is my consulting business. It is live and open for customers.
Polystro is about 95% complete for its first release: a better way to manage AI agent sessions and run multiple development environments in parallel without collisions. I plan to extend it into a much broader product.
Fox Close and Sancterius are products I am building with a different cofounder for each. Both are about 95% complete and targeting their first release by the end of the month.
SaaS Backbone and Notarium are about 80% complete. Both are paused while I focus my token budget on the two releases with deadlines.

These products did not appear as six independent ideas on a whiteboard. One led to the next.

Notarium came first

Notarium was my first real attempt at building a complete product with AI, using Opus 4.5.

I quickly saw how much work goes into the base of any SaaS product before its specific features become useful. Authentication, accounts, permissions, billing, administration, and all the plumbing around the actual idea take a huge amount of time.

So I refactored that base out of Notarium and turned it into SaaS Backbone.

SaaS Backbone became a product in its own right. Notarium became both a product and a proof that the foundation could support a real application.

That relationship matters. I was not dividing my attention between two unrelated codebases. Work on one validated the other.

Then came NodiumLabs.

I was already consulting. Selling the expertise I had developed while building those products was the logical next step. The products created the experience. The consulting business turned that experience into something other companies could use.

Polystro came from the mess

Running several AI-assisted projects exposed another problem.

My development environment was not built for it.

I had terminals everywhere. Browsers everywhere. Agents running in different repositories and worktrees. Ports collided. Cookies and authenticated sessions leaked between projects. Switching to the wrong terminal or browser could damage work that had nothing to do with the task in front of me.

The agents could work in parallel. The environment around them could not.

That missing piece became Polystro.

Each project gets isolated ports, terminals, and a browser identity. Each agent can work in its own Git worktree. Sessions remain attached to the right project. Completed work comes back to one place for review and merging.

Polystro did not create the need to run multiple projects. The pain of running them created Polystro.

Deadlines changed the allocation

Fox Close and Sancterius came later. Each has a cofounder, a short timeline, and a real release deadline. That changed how I allocate my finite token budget. SaaS Backbone and Notarium could pause. Fox Close and Sancterius could not. Polystro continued moving in parallel because it is the system helping me manage the rest.

Context collapse is the real limit

By context collapse, I do not mean the model’s context window.

I mean returning to a project and no longer knowing what I did, why I did it, what was blocked, or what should happen next.

This is the most difficult part of working across several products. Every switch carries a recovery cost. If the project state exists only in my head or inside an old agent session, the work is already in trouble.

The solution is not a better memory. It is external state.

I keep roadmaps, tasks, decisions, and blockers in Markdown files and Linear. When I reopen a project, I ask the AI to inspect the latest commits, review the current codebase, read the remaining tasks, and identify anything that was blocking progress.

That reconstruction takes a few hours for a small scope. It can take a full day when the project has been paused longer or the unfinished work crosses several parts of the system.

This is feasible. It is not free.

The next part I want to integrate directly into Polystro is this project state. Environments and sessions already remain isolated. The roadmap, active tasks, decisions, and blockers should remain attached to the same project as well.

Then reopening a project becomes reconstruction from explicit evidence instead of archaeology.

Parallel work does not mean random work

Today is a good example.

I worked on my personal site. I wrote three blog posts for it. I launched Sancterius to its first preproduction environment. I also kept iterating on Polystro.

That is a normal day now.

Before AI, moving all of those forward on the same day would have been unrealistic. Writing the code alone would have consumed the available time. Now agents can continue executing scoped work while I make decisions, validate results, or move another project forward.

Deadlines still decide where the largest share of the budget goes.

Fox Close and Sancterius need to ship, so they receive priority. Polystro keeps moving because it supports the entire way I work. Notarium and SaaS Backbone remain recoverable but paused.

Paused does not mean abandoned. It means the state is explicit enough that I can resume later without starting from zero.

AI moved the bottleneck

AI did not remove the difficult parts. It moved them.

The bottlenecks are now, in order:

Avoiding context collapse during constant switching.
Reviewing the results.
Allocating a finite token budget, which forces prioritization.
Making product decisions.

Typing code is no longer near the top of that list.

This is easy to misunderstand. If you add AI to the same development process and only ask it to autocomplete more code, you get more code. You do not get the leverage required to run several products.

The leverage comes from changing the process around the code.

The work needs explicit state. Environments need isolation. Agents need bounded scopes. Results need tests and review. Token budgets need to follow deadlines. Projects need a clean pause and resume path.

Otherwise, more output only creates more unfinished work to lose track of.

What remains human

AI can inspect the repository, recover the latest state, implement a task, run tests, and review work produced by another agent.

I still decide what deserves to exist.

Priorities, product direction, taste, and final judgment remain mine. A model can help expose the tradeoffs. It cannot own the consequences of choosing one product, user problem, or deadline over another.

This is also why context matters so much. You cannot make a good product decision if you have forgotten why the project exists or which constraint forced the current design.

The goal is not to keep every implementation detail in my head. The goal is to recover enough reliable context to make the next decision.

The system behind the leverage

You do not need six products. Starting six projects without a way to preserve their state is an efficient method for finishing none of them.

Start with a system that makes one project recoverable:

Keep the roadmap, tasks, decisions, and blockers outside the chat.
Make the AI reconstruct context from the repository and project state before continuing.
Isolate each environment, session, browser identity, port, and worktree.
Allocate the token budget according to deadlines instead of whichever prompt feels interesting.
Review observable results and keep a clear stop condition.

Add more parallel work only when the current work can pause without disappearing.

The tradeoff is simple. AI gives one person much more execution capacity. Every additional stream of work creates more context to preserve and more results to judge.

Ignore that cost and the leverage turns into chaos.

Manage it, and one founder can direct work that previously required a team.

I have never written this much code. I have never shipped this many things in parallel. Somewhere inside that same year, I also wrote a book and released it.

The scarce resource is no longer my ability to produce.

It is my ability to remember, prioritize, and decide.