Running seven things at once

I currently have seven things running, in various states: Pennant, Cusp, Ledgerline, and Marlin, each live and paying its own hosting bill, Quartile mailing a client every Monday, and two ongoing client retainers I don’t write about here by name. People ask, reasonably, how one person keeps that many things alive without it turning into a second full-time job made of nothing but maintenance. The honest answer is that I don’t keep all seven equally alive. I follow two rules that decide, without much daily thought, where my attention goes.

Rule one: maintenance cost is a number, not a feeling

Early on, I ran my product list by instinct. Whichever one felt most urgent that week got the attention. That worked until I had four products, and then it stopped working, because “feels urgent” is a bad signal when everything is a little bit on fire all the time and you have limited hours to spend.

So I started tracking an actual number for each product: hours spent on it in the last 90 days, divided by 90, giving me a rough daily-maintenance-cost figure. Pennant, once I stopped adding features to it, dropped to about four minutes a day, mostly reading the occasional support email. Ledgerline sits around eleven minutes a day, most of that fixing a vendor-specific parser template when a company changes their invoice layout without warning. Marlin, the oldest thing on the list, has crept up to almost forty minutes a day, and seeing that number sitting next to the others is what finally got me looking hard at why, instead of just accepting that old systems are naturally a little more expensive to run.

The number does two things. It tells me which product is quietly becoming expensive before it becomes an emergency, the way Marlin is threatening to. And it tells me, honestly, which products I can afford to add an eighth thing on top of, and which I cannot, without guessing.

Rule two: nothing new until something old drops below its number

This is the rule that actually gates growth, and it is the one I break least often on purpose. Before I start a new product, I look at the current list’s daily-maintenance total. If it is already eating most of the time I have available for this kind of work, I do not start the new thing. I either find a way to cut an existing product’s cost first, the way I did by removing features from Pennant, or I retire something outright, once a product’s number stops being worth what it costs. I don’t have anything I’m ready to call finished yet, but Marlin is the one I keep circling back to on this front.

I broke this rule once, in early 2025, starting Cusp while Marlin’s maintenance cost was already climbing and I had not yet noticed it. For about four months I was running eight things’ worth of attention across seven products’ worth of time, and it showed: Cusp’s early bug reports sat for a week or more before I got to them, which is not the kind of thing that shows up as a metric, but which I remember clearly as the worst stretch of the year. I have tried to actually hold the rule since.

What “seven” really means

Seven active products sounds, from the outside, like a lot to run alone. In hours, it is not, because most of these products have very little daily cost by design. The lesson underneath both rules is that the number of products I run has almost nothing to do with how much time I spend, and almost everything to do with how disciplined I’ve been about keeping each one small enough that its maintenance cost stays low. A product with a wide feature surface and a chatty support inbox is expensive no matter how good the code underneath it is. A product with a narrow, boring job, like Pennant’s single status page, stays cheap for years if I resist the urge to widen it.

If I’m honest, the real skill here is not juggling. It’s saying no to feature requests on things that are already working, more often and more comfortably than feels natural. Every “just one small addition” I’ve said yes to over the years has, without exception, raised that product’s daily number afterward, sometimes by a little, sometimes, as with a retry policy I wrote for Marlin years ago and still haven’t fully unwound, by a lot I didn’t notice for a long time. The shelf stays manageable because I keep each thing on it smaller than it wants to become, not because I’ve found some trick for doing seven things’ worth of work in the hours of one.

I have a couple of ideas I want to build next. Neither gets a slot until something already on this list either shrinks or comes off it. That trade, one in, one out, has become the actual rule underneath both rules above, and it is the one I trust the most.