How I Maintain 19 Products Without Burning Out

"How do you manage 19 products?" I get this question constantly. Usually with a tone of disbelief, sometimes with concern for my mental health. The honest answer is: I almost did not. There was a period where the portfolio nearly crushed me. What I do now is the result of painfully learning what does not work.

Maintaining 19 products as a solo founder is not about working harder or being some kind of productivity superhero. It is about systems that reduce the cost of maintenance, boundaries that prevent context-switching from eating your day, and the discipline to let some products coast while you focus on others.

The Systems

Shared Infrastructure

I have written about my monorepo patterns before, but the impact on maintenance cannot be overstated. When five aviation products share a UI component library, a bug fix in a shared component fixes it across all five products in one commit. When the Agento products share AI integration patterns, an improvement to the streaming logic benefits every agent.

Shared infrastructure is not just about saving time when building features. It is about reducing the maintenance surface area. Nineteen products with completely independent codebases means 19 places where a dependency vulnerability needs patching. Nineteen products with shared infrastructure means maybe five or six.

Automated Monitoring

I do not check 19 dashboards every morning. That would be a full-time job. Instead, I have automated monitoring that alerts me when something needs attention:

• Uptime monitoring pings each product every five minutes and alerts on downtime
• Error tracking aggregates errors across products and surfaces spikes
• Dependency alerts flag known vulnerabilities in dependencies
• Performance monitoring tracks response times and flags degradation

The principle is: if something is fine, I should not be thinking about it. The monitoring systems let me ignore products that are running smoothly and focus attention only where it is needed.

Template-Based Development

Every new product starts from the same template. Next.js App Router, TypeScript, Tailwind CSS, standard project structure, standard deployment configuration. This means I never spend time on boilerplate decisions. It also means every product feels familiar when I open it months later.

The cognitive cost of "How does this project work again?" is real when you have 19 products. Templates and conventions eliminate that cost almost entirely. I can open any product in my portfolio and immediately know where to find components, routes, API endpoints, and configurations.

The Boundaries

Time Blocking by Product Category

I do not randomly bounce between products during the day. Each day has a primary category:

• Two days per week for active development (currently LegalAgento and CodeAgento)
• One day per week for aviation portfolio maintenance and improvements
• One day per week for all other products (maintenance, bug fixes, user support)
• One day per week for writing, research, and strategic thinking

This is not rigid. Emergencies break the schedule, and some weeks demand deviation. But having a default structure means that on any given day, I am context-switching between at most two or three related products rather than jumping between 19.

The Active vs. Maintenance Distinction

Not all 19 products get the same level of attention. At any given time, two or three products are in "active development," where I am building new features, iterating based on user feedback, pushing the product forward. The rest are in "maintenance mode": they are live, they are serving users, but I am not actively adding features.

This distinction is critical. Trying to actively develop 19 products simultaneously would be insane. But maintaining a stable product that is already working requires surprisingly little time, maybe an hour per month for dependency updates, monitoring reviews, and occasional bug fixes.

The hard part is accepting that some products will coast. I have had to internalize that a product in maintenance mode is not a failure. It is a product that works well enough that it does not need my constant attention. That is success.

Saying No to Feature Requests

Every product generates feature requests from users. If I implemented every request across 19 products, I would never stop working. I maintain a strict filter:

• Does this fix a bug affecting current users? → Yes, prioritize it
• Does this serve the core use case better? → Maybe, add to backlog
• Does this add a new use case? → Almost certainly no

Feature creep is the enemy of a multi-product founder. Every new feature is not just the time to build it. It is the ongoing time to maintain it, test it, and support it. Across 19 products, even small features compound into significant maintenance burden.

The Hard-Learned Lessons

Lesson 1: Perfection Is the Enemy of Sustainability

My first few products were over-engineered. I built features nobody used, optimized performance nobody noticed, and wrote tests for edge cases nobody hit. This set an unsustainable standard that nearly broke me when the portfolio grew.

Now, every product gets "good enough" quality. Not sloppy. "Good enough" still means solid, reliable, and well-structured. But it does not mean perfect. The test coverage is comprehensive for critical paths and absent for everything else. The performance is fast enough, not theoretically optimal. The features serve the core use case, not every conceivable use case.

Lesson 2: Automate Deployment Ruthlessly

Manual deployments across 19 products would be a nightmare. Every product deploys automatically on push to main through Vercel. No manual steps, no deploy scripts, no release checklists. Push code, it is live.

This sounds basic, but I have talked to multi-product founders who still have manual deployment steps for some products. Every manual step is a tax on your time and attention. Eliminate every one of them.

Lesson 3: Your Health Is Non-Negotiable

The period where I nearly burned out was characterized by working nights and weekends, skipping exercise, and eating badly. The portfolio did not benefit from those extra hours because my decision quality degraded, my code quality dropped, and my motivation cratered.

Now I work defined hours, exercise daily, and protect my sleep. My output per hour is significantly higher than it was when I was working twice the hours. This is not productivity advice. It is survival advice. A solo founder who burns out has 19 products with zero developers.

Lesson 4: Not Every Product Needs to Grow

Some of my 19 products have found their audience and serve it well at their current scale. They generate value (if not always revenue) and their users are satisfied. Trying to grow every product simultaneously is a recipe for doing everything poorly.

I give myself permission to let products be small. Not every product needs to be a startup. Some can be useful tools that serve a niche audience and require minimal ongoing investment. That is a valid outcome.

The Real Answer

So how do I maintain 19 products without burning out? The real answer is: I do not maintain 19 products simultaneously. At any given time, I am actively building two or three and maintaining the rest through systems that minimize the cost of keeping them running.

The portfolio looks impressive in aggregate, but the day-to-day is not heroic. It is structured, systematic, and deliberately constrained. The hardest skill is not building. It is choosing where to focus and being at peace with everything else running on autopilot.

That is the unglamorous truth about maintaining a large product portfolio as a solo founder. It works, but only if you build the systems to make it sustainable and the discipline to respect your own limits.