Every article about this business, including ours, is about getting to the first sale. Here is the part that decides whether the business is still there in year three: what it costs to keep twenty client apps alive once they are all built and nobody is paying you to build anything.
The short version is that the money is small and predictable, and the work is neither. Most people who get into trouble here priced the money correctly and the calendar not at all.
The money, for twenty clients
| Item | Who pays | Per year, 20 clients |
|---|---|---|
| Apple Developer Program, one per client | Each client, own account | $1,980 ($99 × 20) |
| Google Play Developer, one per client | Each client, own account | $0 after the first year — $25 is one-time |
| Your own Apple account, for test builds | You | $99 |
| Hosting the platform | You | Around $100 |
| Platform licence | You | $0 — bought once, in year one |
| GitHub, OneSignal, Let's Encrypt | You | $0 on the free tiers |
| Build minutes | You | $0 to a few hundred — see below |
Your own running cost is roughly $200 a year plus build minutes. Twenty clients on any sane maintenance fee covers that about forty times over. If this business fails it will not be because of the hosting bill, and anyone selling you a reseller plan on the basis of infrastructure savings is selling you a solved problem.
The $1,980 is not yours, but it is your problem, and we will come back to that.
Build minutes are the one bill that can surprise you
Builds run on hosted macOS machines, and Codemagic's published terms give 500 free macOS M2 build minutes a month, reset on the 1st. Past that they bill $0.095 a minute on M2 and $0.114 on M4. A build is minutes, not hours, so for ordinary months that allowance is generous.
Two things turn it into a real bill. The first is a bad week: a client who wants the icon changed six times burns minutes on every attempt, and a failed build costs the same as a successful one. The second is a detail worth knowing before you hit it — Codemagic states that free minutes are not available on a Team account, only on personal ones. The month you add a colleague is the month your builds start costing money from minute one.
The calendar that is not yours
This is the part that is genuinely different from a website business, and the part nobody warns you about when you are buying in. A website you built in 2024 still works. A mobile app does not, because both stores force you to rebuild on their schedule.
Google, every August. Since 31 August 2026, new apps and updates must target Android 16, API level 36. The deadline moves up one Android version every year, and it has done so every year for several years, so plan on an August for as long as you are in this business.
What happens if you miss it is the part that gets misread. Published apps are not removed. Google's wording is that an existing app must target Android 15, API level 35 or higher, “to remain available to new users on devices running Android OS higher than your app's target API level”. So the app keeps working, existing users keep it and can reinstall it — but it quietly stops being offered to new users on new phones.
That is a worse failure than removal, because nobody notices. The client does not get an error. They get a slow, unexplained decline in installs that starts whenever their customers' handsets turned over, and they will blame whatever else changed that month.
Apple, less predictably. Apple requires submissions to be built against a recent SDK, which is enforced at submission rather than on a published date, so it bites whenever a client next wants a change. Separately, the App Store Improvements process flags an app that has gone three years without an update and has fallen below a minimum download threshold over a rolling twelve months. Both conditions, not either. Flagged developers get an email and a window to ship an update — Apple's original notice gave 30 days and was later extended to 90.
For a small-business app with modest downloads, those two conditions are exactly the ones your quietest clients meet. The café that never asks for a change is the one at risk.
Twenty renewal dates you do not control
Each client holds their own Apple membership, which is correct and required by Apple's rules, and it means twenty cards on file that you cannot see, on twenty dates you did not choose.
The Apple membership is an auto-renewing annual subscription. When the card fails, the membership lapses, and an app whose developer account is no longer in good standing comes off sale. From the client's side this is: the app vanished, and you did something. From yours it is a $99 card decline you had no visibility into eleven months after a launch everyone had forgotten about.
There is no clever fix. There is a boring one: a sheet with twenty renewal dates, a reminder set three weeks before each, and an email that says only “Apple will charge you $99 on the 14th, make sure the card on file still works.” Thirty seconds of work, and it prevents the single most annoying support conversation in this business.
Signing material expires on its own schedule
Provisioning profiles last about a year. Certificates outlive them but cannot be renewed when they lapse — Apple's guidance is to create a replacement before expiry, not after, because there is no renew button.
One decision removes a recurring chore permanently: for push, use the APNs token-signing key rather than a push certificate. Apple's own expiration page states the token-signing key does not expire. A certificate-based push setup adds one more dated thing per client to your calendar, for no benefit.
What it actually costs: the hours
Add it up as a year of obligations, not as a bill:
- One forced rebuild per app, per year, for the Android target API deadline. For twenty apps that is twenty rebuilds in one stretch, around the same August, and they are not spread out.
- Twenty renewal reminders, plus the two or three that fail anyway and turn into a conversation.
- The quiet apps. Any client who has asked for nothing in three years is a candidate for the App Store Improvements email. A trivial version bump resets it.
- Whatever the stores change. In the last few years that list has included privacy labels, data safety forms, account deletion requirements and EU trader verification. None of them were optional, none were announced on your schedule.
None of this is hard work. All of it is work that arrives whether or not anyone paid you that month, which is the entire argument for not selling these apps as one-off projects.
What this means for pricing
The conclusion is not “charge more”. It is that the recurring fee is not a markup on a service you have already delivered — it is the only thing paying for work that is genuinely still coming. If you have been feeling slightly guilty about the monthly, stop: you are being paid to keep twenty apps from quietly falling out of two stores, and that is a real job with real deadlines set by other people.
A useful test for any maintenance fee is whether it still works in the August when all twenty rebuilds land in the same fortnight. If it does, the number is right.
Where this fits
Year one — the licence, the server, the store accounts and what it takes to get to the first client — is in what it actually costs to start. Why each client needs their own store accounts in the first place is in do you need an Apple Developer account for every client. And turning all of this into a number on a quote is in what to charge a small business for their app.