How many apps can one developer actually maintain?
Every "ship fast" story about solo developers assumes building is the bottleneck. It mostly isn't anymore — AI-assisted coding, managed backends, and one-tap store publishing collapsed the time between idea and install. What didn't collapse is the tail: the OS update that breaks something, the review that needs an answer, the listing that's quietly gone stale. That tail is the real ceiling on a portfolio, and almost nobody sizes it up front.
The build cost fell. The carry cost didn't.
A weekend is enough to ship a working app now — a template UI, a generated backend, an app icon from a prompt. That's genuinely new, and it's why the App Store and Play Store keep filling up with one-person catalogs of five, ten, twenty apps. But the part of the job that never got faster is what happens after launch: the app still needs to keep working on every device and OS version someone installs it on, for as long as it stays listed. Building scales with your tools. Carrying an app scales with your calendar, and your calendar doesn't get faster because you used AI to write the first version.
What "maintenance" actually bills you for
It's easy to underestimate this because none of it shows up in a roadmap. It shows up as interruptions:
OS compatibility. Apple and Google each ship a major platform release every year, and each one deprecates an API, changes a permission prompt, or moves a system UI element your screens assumed was fixed. Your app doesn't have to change for this to become work — the platform changed under it.
Dependency and SDK churn. Push certificates expire on a schedule you don't control. Payment SDKs ship breaking major versions. A third-party auth library you added in an afternoon becomes a library you have to re-audit two years later because its maintainer moved on.
Policy drift. App Review guidelines and Play policies get revised through the year, not once. A submission flow that was fine last spring can get flagged on a resubmission for a screen you haven't touched, because the rule around it moved, not the screen.
Support, on every app, not just the flagship. A one-star review saying "crashes on launch" needs a response and probably a fix, whether the app makes $4,000 a month or $40. The review doesn't know which app it landed on.
Listing rot. Screenshots shot against an OS design language two redesigns ago, a description written for a feature set that's since doubled, a subtitle nobody's touched since launch — none of it breaks the app, but all of it quietly taxes conversion on every visit.
The failure mode is quiet, not loud
Apps rarely die from one dramatic event. They fade: a crash rate creeps up on an OS version you didn't test against, a rating drifts from 4.6 to 3.9 over a few months of unanswered reviews, search ranking follows the rating down, and installs taper without a single alert firing. By the time you notice, the fix costs more engineering time than the app has earned in the last quarter. That's the zombie-app trap — not rejected, not pulled, just abandoned by its own users one bad update at a time.
A rough way to size your ceiling
"How many apps" is the wrong unit. The better question is: how many hours a week are you willing to spend on upkeep, indefinitely, for as long as each app stays live? Then classify what's already in your portfolio by how much of that budget it draws:
Low-touch: no accounts, no server you run, a small and stable feature set. These mostly need attention once or twice a year — a build for the new OS, maybe a listing refresh.
High-touch: your own backend, user accounts, anything social or real-time. These generate support volume on their own and need near-continuous attention regardless of revenue.
One high-touch app can consume the same weekly budget as five low-touch ones combined. Adding a sixth low-touch utility might cost you nothing measurable; adding a second high-touch app might mean the first one starts slipping.
When to sunset instead of maintain
Sunsetting isn't failure — it's a capacity decision, and treating it as one keeps you from making it too late. Some honest signals: the app's revenue doesn't cover your developer account share plus a fair hourly rate for the support it demands. You're avoiding opening the project because the last update broke something you still haven't fully diagnosed. The listing hasn't been touched since a design language the OS itself has abandoned. None of these mean the app was a mistake — they mean it's done earning your attention relative to what else is in the portfolio.
Before pulling the plug entirely, though, check whether the thing dragging on your time is actually the code — or just the listing. A stale screenshot set and an outdated description cost conversion every single day an app stays live, and unlike a rewrite, refreshing them doesn't require touching a line of Swift or Kotlin. If an app across your portfolio hasn't had its store page updated since launch, that's the cheapest lever available before you decide it's not worth carrying.
Keep the listing side cheap
This is the one part of maintenance ShotCanvas actually shrinks: refreshing screenshots and metadata across a whole portfolio without opening a design tool for each app individually. Batch-render a new template across every screenshot set, regenerate copy with AI, and publish straight to App Store Connect and Google Play — the afternoon-per-app job becomes minutes per app.