I have a full-time job and roughly ten hours a week for my own products. Until recently, I was spreading those hours across seven shipped products and four ideas.
Ten hours across eleven things is less than one hour per project per week. At less than an hour per project, I wasn't giving any of mine enough time to test a growth plan.
So I ran a portfolio review. One afternoon, every project on the table, and a rule I borrowed from finance: decide the exit criteria before you look at the position. Four projects did not survive it.
Ten available hours, forty hours of work
Before judging any single project, I wrote down two numbers:
- Capacity: about 10 hours per week.
- Demand: what each project actually needs to have a chance—not to be maintained, but to grow.
A community product needs content, moderation, and distribution every single week. A paid Mac app needs continuous distribution experiments. A consumer game needs live operations. Summed honestly, my portfolio demanded forty-plus hours a week. I had ten.
I chose to reduce the number of active projects.
One attack project, everything else defends
The structure I landed on:
- One attack project gets half of all capacity. It is the only project allowed to have growth ambitions this quarter.
- One low-maintenance product stays on the market and gets a small, strictly bounded slot for distribution experiments—no new features until distribution shows signs of life.
- Content and free tools act as shared infrastructure, feeding search traffic to everything else. My shared cost allocator and the new runway calculator exist for this reason.
- Everything else is stopped, archived, or handed a written revival condition.
The uncomfortable part is that "everything else" included products I still liked. Liking a product is not a strategy.
The four kills, and what actually killed them
Each kill got one honest sentence, written down:
- An AI video prompt tool. The platforms it served built the same feature natively. A middleman product whose two ends merged has no middle left.
- A casual math game. A leaderboard with a dozen players, no growth loop, and yearly forced maintenance from OS updates. Cost of keeping it exceeded everything it would ever return.
- A half-finished learning app. The browser-extension version had found a niche; the app version would have entered a crowded market with none of the extension's distribution advantages. The extension stayed, the app died.
- An over-engineered internal research system. I had spent more effort hardening its infrastructure than running the question it was built to answer.
In this review, weak distribution and maintenance demands drove several of my decisions.
The surprise: my most active product was one I had abandoned
The review also produced one genuine surprise. A browser extension I had not touched in months had quietly collected hundreds of organic installs and a stable group of weekly users—entirely from store search, with zero marketing.
Meanwhile the product I actively promoted on social channels had a handful of downloads to show for it.
The extension was getting organic installs while the product I promoted on social channels had few downloads. I am prioritizing store and search discovery for the next quarter.
Kill criteria, written before feelings arrive
Every surviving project got a decision gate, written now, evaluated in 90 days. For example:
- The attack project must show a minimum level of weekly participation and repeat usage, or it drops to maintenance mode.
- The low-maintenance app must reach a concrete download and paid-conversion threshold, or feature work stays frozen.
- Revived ideas must earn their first line of code with evidence, not enthusiasm.
The exact numbers matter less than the mechanism: the thresholds are written down today, and in 90 days I read them instead of negotiating with myself.
Knowing what each product actually contributes
None of this works if you cannot see what each product earns and costs. My review leaned on numbers I already track monthly: revenue per product, direct costs, each product's share of subscriptions the whole portfolio uses, and how much cash the remaining projects can burn before the hobby stops paying for itself.
Disclosure: I make MarginDeck. This article describes my own work on the product.
That tracking is the job of MarginDeck, the local-first Mac app I build—it shows recorded revenue, scheduled costs, and estimated contribution profit per product, which is exactly the evidence a review like this needs. If you only want the quick version, the free runway calculator answers the single most clarifying question: how many months can this portfolio afford to keep going as it is?
If you want to run the same review
One afternoon, five steps:
- Write down your true weekly capacity.
- List every project with one sentence: what it needs per week to grow.
- Pick exactly one attack project. Everything else defends or dies.
- For each survivor, write a 90-day threshold you are not allowed to renegotiate.
- For each kill, write the one-sentence cause of death—you will reuse these lessons more than any feature you ever shipped.
Killing four projects did not feel like losing four products. It felt like finally giving the remaining ones a chance.