How I Maintain 9 Products Without Burning Out

"How do you manage 9 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 doesn't work.

Maintaining 9 products as a solo founder isn't about working harder or being some kind of productivity superhero. It's 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've written about my monorepo patterns before, but the impact on maintenance can't 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 AI products share integration patterns, an improvement to the streaming logic benefits every product.

Shared infrastructure isn't just about saving time when building features. It's about reducing the maintenance surface area. Nine products with completely independent codebases means nine places where a dependency vulnerability needs patching. Nine products with shared infrastructure means maybe five or six.

Automated Monitoring

I don't check nine dashboards every morning. That would be a full-time job. Instead, I've 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's 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 9 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 don't randomly bounce between products during the day. Each day has a primary category:

• Two days per week for active development (currently ClickAi and HackIfy)
• 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 isn't 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 nine.

The Active vs. Maintenance Distinction

Not all 9 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 9 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've had to internalize that a product in maintenance mode isn't a failure. It's a product that works well enough that it doesn't need my constant attention. That's success.

Saying No to Feature Requests

Every product generates feature requests from users. If I implemented every request across 9 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 isn't just the time to build it. It's the ongoing time to maintain it, test it, and support it. Across 9 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 doesn't 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 9 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's live.

This sounds basic, but I've 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 didn't 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 isn't productivity advice. It's survival advice. A solo founder who burns out has 9 products with zero developers.

Lesson 4: Not Every Product Needs to Grow

Some of my 9 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's a valid outcome.

The Real Answer

So how do I maintain 9 products without burning out? The real answer is: I don't maintain 9 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 isn't heroic. It's structured, systematic, and deliberately constrained. The hardest skill isn't building. It's choosing where to focus and being at peace with everything else running on autopilot.

That's 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.