Six apps. SYM (savings challenges), Zingo (translation), Snappy Menu (restaurant menus), Speaking Bee (language learning), ShelfWorth (product tracking), and GeoMaster (geography quiz). All live on the App Store. All need updates, bug fixes, ASO, and customer support.
When people hear that number, the first question is always "why?" The second is "how?" I'll skip the why — each app started as a genuine problem I wanted to solve, and I'm not great at killing my own projects. The how is more useful.
The portfolio trap
In early 2025, I tried to work on all six apps equally. Monday was SYM, Tuesday was Zingo, Wednesday was Snappy Menu. You can guess how that went.
Every context switch costs you 20 to 30 minutes of ramp-up time. When you're switching between entirely different codebases, different domain logic, and different user bases, that cost is even higher. I was spending half my available time just remembering where I left off.
Worse, nothing was moving fast enough to matter. An hour on each app per week doesn't ship features. It ships minor bug fixes and the occasional UI tweak. Users notice when an app stops getting meaningful updates, and the reviews reflect it.
I needed a different approach.
The tier system
Not all apps deserve equal attention. That sounds harsh, but it's the most important decision I made. I split the portfolio into three tiers based on two things: revenue potential and user growth trajectory.
Tier 1: Active investment. SYM lives here. It has the clearest monetisation path, the most engaged users, and the biggest market. SYM gets 60% of my development time and nearly all my marketing effort. New features, content, App Store experiments — everything.
Tier 2: Maintenance plus. Zingo and GeoMaster. These apps have steady users and decent retention. They get bug fixes, OS compatibility updates, and the occasional small feature. Maybe 25% of my time, split between them. I'm not pushing growth hard, but I'm not letting them rot either.
Tier 3: Life support. Snappy Menu, Speaking Bee, and ShelfWorth. These get the minimum: crash fixes, iOS version compatibility, and App Store compliance updates. That's it. Maybe 15% of my time across all three, and most of that is automated.
This sounds ruthless. It is. But trying to grow six apps equally means growing none of them. The tier system means at least one app is moving fast enough to break through.
I reassess the tiers every quarter. If GeoMaster suddenly picks up traction, it moves up. If SYM stalls, I need to figure out why before reallocating. The tiers aren't permanent — they're a resource allocation tool.
Shared foundations
Six separate codebases would be unmanageable. So I don't have six separate codebases.
I maintain a shared Swift package that handles the things every app needs: networking layer, analytics integration, in-app purchase logic, review prompt timing, onboarding flow patterns, and common UI components. When I improve the networking layer for SYM, every app benefits.
This was a significant upfront investment. Extracting shared code from five different implementations into a single package took weeks. But the payoff is compound. A bug fix ships once and deploys everywhere. A new iOS API adoption happens in one place. The total maintenance burden across six apps is maybe 2x what a single app would be, not 6x.
The rule is simple: if I write it twice, it goes in the shared package. No exceptions.
Automation is not optional
At one app, you can get away with manual processes. At six, you can't. Every manual step multiplied by six is a full day's work that produces nothing visible to users.
CI/CD. Every app has a GitHub Actions pipeline that runs tests, builds, and submits to TestFlight on every merge to main. I don't manually archive and upload builds. I haven't opened Xcode's organiser in months. Push to main, wait for the notification that the build is processing.
Dependency updates. Dependabot monitors every repo. Minor and patch updates get auto-merged if CI passes. Major updates get a PR that I review in batches, usually Sunday morning with coffee.
App Store metadata. I use fastlane to manage screenshots, descriptions, and keywords across all six apps. When I update SYM's screenshots, I run one command. When I need to update the privacy policy URL across all apps, it's a single script.
AI agents. This is the big one. I run an AI agent called Chris that handles a surprising amount of the operational work. It monitors repos for failing CI, scans for code quality issues using aislop, drafts content for social media, does competitive research, and even opens PRs for straightforward fixes. I review its work in the morning. It's like having a junior developer who works overnight and never complains.
The cumulative effect of all this automation is massive. I estimate it saves me 8 to 10 hours per week. That's the difference between the portfolio being sustainable and it being a second full-time job.
ASO across a portfolio
App Store Optimisation gets interesting when you have multiple apps. You're not just optimising one listing — you're managing a portfolio of search positions.
The biggest advantage is data. With six apps in different categories, I see patterns in what works across the App Store, not just within one niche. Keyword strategies that work for GeoMaster (education category) teach me things I can apply to SYM (finance category). Screenshot styles that boost conversion for Zingo get tested on other apps.
I track keyword rankings, conversion rates, and impression data for all six apps in a single spreadsheet. Every two weeks I review the numbers and make adjustments. Most changes are small: swapping a subtitle, testing a new first screenshot, adjusting keyword density in the description.
One non-obvious benefit: cross-promotion. Each app's listing has a "More by this developer" section. Users who like one app see the others. It's free, passive distribution. SYM users who also care about language learning discover Speaking Bee. GeoMaster users who travel find Zingo useful. The portfolio creates its own discovery network.
When to sunset vs invest
The hardest question in a portfolio is: when do you kill an app?
I haven't sunsetted any of my six yet. But I've thought about it seriously for two of them, and I have a framework for making that call.
Revenue trajectory. Is it trending towards zero, or is there a floor? An app making £30/month with stable numbers is fine on life support. An app making £30/month and declining needs a decision.
Maintenance cost. How much time does it take to keep alive? If an iOS update requires a week of work to fix compatibility issues in an app that generates no revenue and has declining users, the math is clear. But if the shared package handles most of the heavy lifting, the marginal cost of keeping it alive might be almost nothing.
Strategic value. Some apps are worth keeping alive even without direct revenue. They demonstrate breadth on my developer profile. They serve as testing grounds for ideas. ShelfWorth helped me prototype a barcode scanning approach that I later used in a client project.
Emotional attachment. This is the trap. I built every app because I cared about the problem. That makes it hard to let go. The framework exists specifically to override emotions with data. If the numbers say sunset, I sunset.
The tier system helps here too. An app on life support isn't costing me much. It's only when an app demands Tier 1 attention without Tier 1 results that the decision becomes urgent.
The weekly rhythm
Systems only work if they have a cadence. Here's mine.
Monday. Review the previous week's metrics across all apps. Downloads, revenue, crash rates, review scores. Takes 30 minutes with everything in one dashboard. Flag anything that needs attention.
Tuesday to Thursday. Deep work on Tier 1 (SYM). New features, marketing experiments, content creation. This is protected time. No context switching unless something is on fire.
Friday evening. Tier 2 and Tier 3 batch. Review Dependabot PRs, merge what's clean, fix what's broken. Process App Store review responses. Check crash logs. This takes 2 to 3 hours and covers all five non-primary apps.
Sunday morning. ASO review. Check keyword rankings, read new reviews, update metadata if needed. Plan the next week's content. 1 to 2 hours.
Total: roughly 15 to 20 hours per week across all six apps, on top of a full-time job. It's a lot. But it's structured, predictable, and sustainable. The key word is sustainable.
What I'd tell someone starting out
Don't start with six apps. Seriously. I accumulated these over three years, and each one shipped before the next one started. Build one app. Make it good. Learn the full lifecycle — development, launch, marketing, support, iteration. Then, and only then, consider a second.
But if you already have multiple apps, here's the short version of everything above:
Tier ruthlessly. Not every app deserves your best effort right now. Pick one to push hard, maintain the rest.
Share everything. Extract common code into packages. Reuse patterns. Make improvements compound across the portfolio.
Automate everything that doesn't require taste. CI/CD, dependency updates, metadata deployment, monitoring. If a computer can do it, a computer should do it.
Batch context switches. Don't bounce between apps daily. Dedicate blocks of time and protect them.
Review metrics weekly, not daily. Daily numbers are noise. Weekly trends are signal.
Be ready to let go. The portfolio should serve your goals, not the other way around. If an app isn't earning its place, acknowledge it.
Six apps solo isn't for everyone. Most weeks I love it. Some weeks I wonder what I'm doing. But the system keeps things moving even when motivation dips, and that's the whole point. Motivation comes and goes. Systems persist.