How much time should I give each side project?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

There's no fixed number of hours that works for every project — a brand-new app and a stable earner with 200 paying users need wildly different attention. The honest answer is: allocate time by stage and by revenue-per-hour, not evenly across your portfolio, and review the split on a fixed cadence instead of by gut feel.

Most solo founders running several products default to even splits because it feels fair. Fair isn't the goal. The goal is getting the highest return on the hours you have, across a portfolio, not per app in isolation.

Why "equal time for every project" fails

If you run 5 products and give each one 8 hours a week, you've made an implicit bet: that every product deserves equal investment regardless of where it is in its life. That's rarely true.

A product you launched last month needs discovery — talking to users, fixing onboarding, finding out if anyone will pay. A product that's been live for two years with a flat but real subscriber base mostly needs maintenance: dependency updates, support tickets, the occasional feature that reduces churn. Giving both 8 hours a week either starves the new one of the momentum it needs to find product-market fit, or wastes hours on a mature product that would run fine on 2 hours a week.

Equal time also hides a worse problem: it lets failing projects coast. If kill criteria would tell you to shut something down, but it's still getting its "fair share" of hours, you're subsidizing a decision you already made and haven't acted on. See real numbers from a 10-app portfolio for what that coasting actually costs over time.

A stage-based allocation that works for 1-20 products

Instead of splitting hours evenly, bucket each product into a stage and assign a rough hour range per week. Adjust the ranges to your own capacity, but keep the relative proportions:

Discovery / pre-revenue (0-3 months old, no reliable signal yet) This is where most of your discretionary time should go. You're testing distribution, pricing, onboarding. Budget 60-70% of your total product hours here if you have a product in this stage at all — this phase is short by design, not a permanent state.

Growth (revenue exists, trend is clearly up) This earns the second-biggest share. You know the thing works; now you're removing friction and doubling down on whatever channel is bringing users. 20-30% of your time, concentrated on the 1-2 changes most likely to move the trendline, not a dozen small tweaks.

Maintenance (flat revenue, stable users, no active experiments) This should take the least time per product, often just a few hours a month: dependency bumps, responding to support, watching for churn spikes. If a "maintenance" product is quietly eating 10 hours a week, something's wrong — either it's not actually stable, or you're procrastinating on a harder project by tinkering with an easy one.

Decline (revenue or usage trending down for 2+ consecutive review periods) This is where you apply your kill criteria, not more hours. More time rarely reverses a real decline — it just delays the decision. If you haven't set kill criteria yet, defining them before launch — or at least before the trend starts — saves you from rationalizing more hours later.

The exact percentages matter less than the habit: know which bucket each product is in, right now, and let that bucket decide how many hours it gets this month.

Weight by revenue per hour, not just revenue

Two products can both do $800/month, but one takes 2 hours a week of upkeep and the other takes 15. That second one isn't actually worth $800 to you — it's worth $800 minus the opportunity cost of 13 extra hours you could've spent on discovery for something else.

To compute this, you need a rough hours estimate (your own time tracking, even a crude weekly guess) next to actual revenue, pulled from wherever that product bills — Stripe, RevenueCat, App Store Connect, Google Play. If you're tracking revenue across subscription billing and consumption billing for the same app, tracking Stripe and RevenueCat together is worth getting right before you start making time-allocation decisions on top of messy numbers.

Once you have revenue-per-hour by product, re-rank them. Low revenue-per-hour products aren't automatically kill candidates — a new discovery-stage product should have terrible revenue-per-hour, that's expected. But a 2-year-old "maintenance" product with bad revenue-per-hour is a real signal.

Set a review cadence, not a daily check-in

Checking allocation daily is how founders end up chasing the loudest fire instead of the most important one. A monthly or biweekly review — where you actually look at revenue, trend direction, and hours spent per product side by side — is enough to catch a drifting allocation before it costs you a quarter.

This is also where a dashboard that pulls metrics automatically beats a mental model. If you're eyeballing each app's App Store Connect, Play Console, and Stripe dashboard separately, "stage" and "trend" become vibes instead of numbers. SoleOS pulls metrics from connectors like Stripe, RevenueCat, GA4, and both app stores into one view, so you can see trend direction per product without opening ten tabs — and it's one honest way to run that monthly review, not the only one. A spreadsheet with revenue pasted in monthly works fine too, especially under 3-4 products — see SoleOS vs a spreadsheet for where the line is.

Disclosure: SoleOS is built by the same team writing this post, so take the product mention as self-interested — we think it's useful, we don't think it's the only way to do this, and under a handful of products a spreadsheet or your app stores' native dashboards are genuinely enough.

A simple weekly check

If you want a lightweight version of this without building a whole system: write down, for each product, its stage (discovery/growth/maintenance/decline) and the hours it got last week. Once a month, compare that to revenue trend. If a maintenance product got more hours than a growth product, ask why. If a decline-stage product got hours at all beyond what your kill criteria require, ask why.

That single comparison — stage vs. hours vs. trend — catches most of the misallocation that an even split hides.

Frequently asked questions

Should a brand-new side project get more time than an established one?

Usually yes, for a limited window. New products need discovery work — figuring out if there's demand, fixing onboarding friction, testing pricing — that compounds fastest early. An established product with flat, predictable revenue needs upkeep, not discovery, so it should take proportionally less time once it's stable.

How do I know when a product has moved from growth to maintenance?

Watch the trend over two or three consecutive review periods, not a single week. If revenue and active users have plateaued and you're not running active experiments, it's likely in maintenance. If you're still making weekly changes specifically to try to move the number, it's still growth stage, even if the number itself has been flat for a bit.

Is it ever right to give a declining product more time?

Rarely, and only if you have a specific, time-boxed hypothesis for the decline (a pricing change, a platform policy shift, a broken funnel step) that you can test and measure within a few weeks. Open-ended extra time on a declining product is usually avoidance of a kill decision, not a real turnaround plan.

What if I only have time for one or two products right now?

Then allocation is simpler, not less important — most solo founders with 1-2 products still unconsciously overinvest in the one that's more fun to build and underinvest in the one that's actually making money. The stage-based question still applies even at small scale: which one is in discovery, and which one just needs steady upkeep?

Do I need a dashboard to do this well?

No — a notebook or spreadsheet tracking stage, hours, and revenue trend per product covers the basics, especially with 2-3 products. It becomes more worth automating once you're checking 5+ sets of app store and billing dashboards and the manual pull-together starts eating the same hours you're trying to protect.