DEV Community: vicgorn-design

The Second Year: What Twenty Client Apps Cost to Keep Alive

vicgorn-design — Fri, 30 Oct 2026 14:36:24 +0000

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.

Do You Need an Apple Developer Account for Every Client?

vicgorn-design — Thu, 29 Oct 2026 19:01:58 +0000

This is the question that comes up on the second client, never the first. You have one app live, the process worked, and now you are looking at doing it nine more times ‚Äî and paying Apple $99 nine more times, out of your margin, feels absurd. Surely you can publish them all from the account you already have?

You cannot, and the reason is not billing. It is a written App Review guideline, and it is the single rule that decides the shape of this entire business.

The rule

Guideline 4.2.6 of Apple's App Review Guidelines exists specifically for services like this one. It reads:

‚ÄúApps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences.‚Äù

Read the second sentence again, because it is unusually direct for Apple. It does not say the apps must be different enough. It names the practice ‚Äî a service submitting on behalf of its clients ‚Äî and says do not do it.

So the answer to the question is yes: each client needs their own Apple Developer Program membership, enrolled in their own name, and their app is submitted from there. The client is the provider of the content, so the client has to be the submitter.

What that does not mean

It does not mean the client does the work. This is where most people get the rule backwards and either give up on the model or hand a non-technical caf√© owner a copy of Xcode.

The account belongs to the client. The labour does not. Apple has a documented mechanism for exactly this, and using it is both normal and expected:

The client enrols and becomes the Account Holder. Their legal name or company name is what appears as the seller on the App Store listing.
They invite you into their App Store Connect account as an App Manager, which is the role that can upload builds, edit the listing and submit for review. Adding a user requires the Account Holder, Admin or App Manager role, so the client does this part themselves, once.
Access to Certificates, Identifiers & Profiles is a separate checkbox on that invitation, not part of the role. You need it ticked to handle signing, and it is the thing people forget, which then costs an email and another three days.
You do not need your own paid membership to be in their account. An individual enrolment can add up to 50 such users, and Apple is explicit that they get App Store Connect access only ‚Äî they are not part of the team and receive no other membership benefits.

One practical detail worth putting in your onboarding email: the invitation expires after three days. It can be resent, but a client who opens it on Monday and gets to it the following weekend has to be chased, and you will do this often enough to want the sentence prewritten.

The third option, which Apple offers itself

The same guideline ends with an alternative most people never read as far as:

‚ÄúAnother acceptable option for template providers is to create a single binary to host all client content in an aggregated or ‚Äòpicker‚Äô model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.‚Äù

One app, under your account, containing all your clients. No per-client $99, no invitations, no chasing. It is a legitimate route and Apple names it.

It also destroys the product you are selling, in most cases. The thing a small business is actually buying is their icon on their customer's home screen, with their name under it. In a picker app they are an entry in somebody else's directory, they cannot send a push that belongs to them, and they are one tap deeper than the competitor who paid for a real app.

Where it does work: a franchise with one brand and many locations, an organiser running many events a year, a trade association with member businesses. The common factor is that the clients already share an identity with each other. If they do not, you are selling a directory and should price it like one.

Google Play is a different problem, not a smaller one

Google has no equivalent of 4.2.6, and the fee is a one-time US$25 rather than $99 a year. On paper, the Android side is trivial. In practice it has become the harder half, for a reason that has nothing to do with templates.

A developer account created as a personal account after 13 November 2023 must, before it can publish to production, run a closed test with at least 12 testers opted in continuously for 14 days. Google's own help page states that requirement and scopes it to personal accounts created after that date. It says nothing either way about organization accounts, so treat the widely repeated claim that companies are exempt as something to verify for the specific client in front of you, not as a given.

What this means operationally is that an Android launch for a brand-new client is two weeks longer than you think, and the two weeks are not yours to compress. You cannot start the clock until the client's account exists, and internal testing does not count toward it ‚Äî only closed testing does. Personal accounts must also verify access to an Android device through the Play Console app.

Put the fourteen days in the quote. A client who is told about them up front treats them as a process; a client who discovers them in week three thinks you missed a date.

What it costs, per client

Item	Who pays	Amount
Apple Developer Program	Client, own account	$99 per year, recurring
Google Play Developer	Client, own account	$25, one time
Your access to both	Nobody	Free ‚Äî invited user, no membership needed
Your own developer account	You	$99 a year, for your own test builds and demos

The number that matters is the first one, and it is recurring. It is the client's cost, not yours, which is a conversation worth having early ‚Äî a $99 annual charge appearing on a caf√© owner's card eleven months after launch, unexplained, is how a renewal gets cancelled and an app quietly disappears.

The detail that catches people in Europe

If the client's app is distributed in the EU and they are a trader ‚Äî which covers anyone earning money through the app, including via paid downloads or in-app purchases ‚Äî Apple requires verified trader status, and the contact details that come with it are published on the App Store listing: an address, a phone number and an email.

Apple set 17 February 2025 as the date from which apps without verified trader status would be removed from EU storefronts. For a company client this is paperwork. For a sole trader operating out of their home it is a home address on a public page, and some of them will refuse once they understand it. Better that they understand it from you, in week one, than from a removal notice.

What to tell the client

The whole thing compresses into four sentences, and having them ready is the difference between a short call and a confused one:

The app has to be published under your name, not ours ‚Äî that is Apple's rule, not our preference.
It costs you $99 a year to Apple and $25 once to Google, paid directly, and we do not mark it up.
You sign up, you click one button to give us access, and we do everything after that.
It means the app is yours. If you ever leave us, it stays on the store under your account.

That last line is worth saying out loud even though it costs you leverage, because the objection behind the question is almost never the $99. It is the suspicion that they are about to be locked into something. Telling them plainly that the asset is theirs tends to close the topic faster than any discount.

And one argument for the rule

It is easy to read 4.2.6 as Apple making your life harder. It is also the rule that stops the obvious disaster in this business: thirty client apps published under one account, sharing one fate. Accounts get terminated, cards expire, the person who set it up leaves. Under 4.2.6 a problem with one client's account is a problem with one client.

Mostly, though, it is the rule that makes the model honest. You are selling a business its own app, and after the invitation is accepted, that is literally what it owns.

Where this fits

The other rule that decides whether the app ships at all is Guideline 4.2 on minimum functionality, which is about the app itself rather than who submits it. What the whole first year costs, store fees included, is in what it actually costs to start. And what to charge once you have worked out that the $99 is not your problem is in what to charge a small business for their app.

The One Question That Tells You If a Business Needs an App

vicgorn-design — Mon, 26 Oct 2026 17:31:13 +0000

A reader asked me something after a piece about which small businesses actually buy an app: that article describes a test you run in your own head before calling. But what do you actually say on the phone? What is the one question that sorts the prospects fastest?

It is a better question than the one I had answered, so here is the answer properly.

Don't ask the obvious thing

The instinct is to ask about frequency directly. "How often do your customers come back?" It seems like exactly the right question, and it is nearly useless.

Every owner says they have lots of regulars. They are not lying; they genuinely believe it, because the regulars are the ones they remember. The person who came once and never returned left no impression at all. You are asking someone to estimate a number from a sample they cannot see, and they will answer confidently and wrongly.

Ask anything that invites self-assessment and you get the owner's self-image, not their business.

The question that works

"When you want to tell your customers something, what do you do?"

It sounds like small talk. It is phrased as a practical question about their routine, not an evaluation, so they answer without any instinct to perform. And the answer tells you almost everything you need.

Because to tell your customers something, you must first have customers you can reach a second time. The question tests for a retained audience without ever mentioning one.

How to read the answer

There are roughly four replies, and each one is a different conversation.

"I post on our Facebook page" or Instagram, or the WhatsApp group. This is the most common good answer. They have an audience, they have the habit of reaching it, and they are quietly frustrated that only a fraction sees each post. You are not introducing a new idea, you are selling a better version of something they already do. Ask what reach a post gets them; most know, and the number is usually depressing enough to make your case for you.

"I send the newsletter" or "I text the list". The strongest answer there is. Somebody who maintains a mailing list has already decided that keeping customers is worth work. They understand open rates, they understand why reaching people matters, and the pricing conversation will be short.

"I put a sign up" or "I tell them when they come in". This one is ambiguous and worth probing. A busy café owner who tells people at the counter may well have a strong returning audience and simply no digital habit. One follow-up sorts it: "if you had to reach them tomorrow without waiting for them to walk in, could you?" If the answer is no and that bothers them, you have a prospect. If the answer is no and they shrug, you do not.

"I'd advertise" or a pause, or confusion at the question. This is the one to listen for. It means there is no group of people they think of as "our customers" — there is just a flow of strangers. An app has nothing to do in that business. They will buy it if you push, use it for a month, and blame you in the third. Thank them and move on.

It also hands you the pitch

The useful part is that the answer tells you what to compare yourself to, in their words rather than yours.

If they said Facebook, you are competing with organic reach, and you can talk about the difference between a post a tenth of them might see and a notification almost all of them will. If they said newsletter, you are talking about open rates and the fact that nobody under thirty opens email. If they said "I tell them at the counter", you are talking about the customers who did not come in this week, which is the ones the business is quietly losing.

You have not had to explain what an app is. You have explained how it fixes something they just told you annoys them.

The backup question

Occasionally the first one does not land — usually with businesses where the owner is not the one dealing with customers. Then:

"Roughly what share of your takings comes from people who've bought before?"

Most owners either know this number or can estimate it within ten points, because it maps onto how they think about the business. And the ones who have no idea at all have answered you anyway: if nobody has ever needed to know, it is because nobody comes back.

What not to ask

"Have you thought about an app?" Everyone has thought about an app. You will get a polite yes and learn nothing, and you have framed the call as a pitch in the first sentence.
"Do you have a website?" You can check this yourself in ten seconds, and you should have checked it before dialling. Asking questions you could have answered yourself signals that you did not prepare.
Anything about budget, early. You do not yet know whether you want this client. Qualifying on money before qualifying on fit is how you end up selling to the wrong person at the right price.

Leaving the call early is a skill

If the answer puts them in the fourth group, end it kindly and quickly. Not because the call is lost — because it was never there, and the time you spend persuading somebody into a rhythm they do not have is time taken from the next five calls.

There is also a version of this that pays off later. "Honestly, an app wouldn't do much for you right now — you'd need people coming back regularly first." Owners remember the person who talked them out of spending money. A surprising number come back a year later when something has changed, and they arrive already trusting you.

Where this fits

This is the first two minutes of a call. What happens after a yes — what to quote and the floor below which the work does not pay — is in what to charge a small business for their app. What it costs you to be in a position to say yes is in what it actually costs to start. And the shape of the business as a whole, including the part that breaks at about forty clients, is in selling apps to local businesses.

A Third of the AI Crawlers Hitting Our Site Were Fake

vicgorn-design — Sun, 25 Oct 2026 19:11:22 +0000

I wanted to know whether AI assistants actually read our site, so I grepped the nginx logs for the user agents. The numbers looked encouraging:

ClaudeBot       1136
GPTBot           420
PerplexityBot    356
Applebot         230
ChatGPT-User     213
OAI-SearchBot    196

Then I checked where those requests actually came from, and a third of them were not who they said they were.

The companies publish their IP ranges

This is the part most people do not know exists. Every serious crawler operator publishes the address ranges their bots use, specifically so that you can verify them:

openai.com/gptbot.json — the training crawler
openai.com/searchbot.json — the one that builds the index ChatGPT searches
openai.com/chatgpt-user.json — live fetches when a user's question triggers browsing
search.developer.apple.com/applebot.json — Applebot, which serves Spotlight, Siri and Apple Intelligence

Each file is a list of CIDR prefixes. Checking a log line against them is twenty lines of code and no dependencies:



import ipaddress, json, urllib.request

Who Actually Buys a Mobile App, and Who Never Will

vicgorn-design — Thu, 22 Oct 2026 20:52:25 +0000

Two sales calls, same script, same price. The first one is over in under a minute: the owner is polite, says it sounds interesting, and never replies again. The second one ends with the owner asking how soon it can be in the App Store.

Nothing about the pitch changed. What changed was who was on the other end of the phone. Learning to tell those two apart before you dial is most of this job, and it has very little to do with what industry they are in.

You are not selling an app. You are selling the second visit.

An icon on someone's home screen is a standing invitation to come back. That is the entire product. Everything else — the design, the push notifications, the native screens — exists to make the second visit easier than it was before.

Which means the business has to have a second visit to sell in the first place. If their customer buys once and gets on with their life, there is nothing for the icon to do. The owner senses this immediately, even if they cannot put it into words, and that is the polite call that goes nowhere.

So the question is never "would this business like an app?" Everyone would like an app. The question is whether their customers have a reason to open it twice.

The home screen test

Here is a way to run that question in your head in about five seconds. Picture their customer's phone. Now picture this business's icon sitting on it, next to the banking app and the messages. Ask what makes that person tap it on an ordinary Tuesday.

If you can answer in one short sentence — to see what time the class is, to reorder the usual, to check if anything new came in, to book the next appointment — you have a prospect. If you find yourself constructing a scenario, you do not.

The honest version of this test is that it eliminates most of the list you were planning to call. That feels like bad news for about a day, and then it feels like having been handed back three months.

Four reasons a tap happens

Rather than memorising a list of industries, it is more useful to know the four things that produce that ordinary-Tuesday tap. Almost every client worth having has at least one of them, and the ones with two are the easiest sales you will make.

1. There is a schedule that moves

Anything where the information changes on a weekly rhythm and the customer has to check. Gyms, yoga and dance studios, martial arts clubs, swimming schools, community centres. The timetable currently lives on a wall, in a group chat, or on a web page the owner updates when they remember.

These are good clients for a reason that has nothing to do with the app: the owner already sells monthly memberships. They think in recurring revenue already, so your monthly fee needs no explaining. You are the only vendor they will speak to that week who does not have to justify the word "subscription".

2. There is a basket

A real shop with real repeat customers — WooCommerce, Shopify, or a local retailer whose site already takes money. Coffee roasters, pet supplies, health food, anything consumable.

This is the least work you will ever do for a setup fee, because the site already is the product: already mobile, already maintained, already full of things to come back for. With the native storefront templates the catalogue and the cart become real app screens rather than a web page in a frame, while checkout stays on the shop's own page so every payment method they already use keeps working.

3. There is a queue

Businesses where the whole operation is appointments. Salons, barbers, dentists, physiotherapists, tattoo studios, dog groomers, garages.

Do not pitch these on convenience. Pitch them on no-shows. Every owner in this category can tell you their no-show rate from memory and it annoys them more than almost anything else in the business. A reminder that arrives as a notification rather than an email that goes unread is a number they can watch move. That is a very short path from install to "this paid for itself".

4. There is an audience

Somebody publishing on a rhythm to people who have a habit of reading it. Local news, community magazines, schools, clubs, congregations, associations, property agencies with listings that change daily.

Push notifications are not a feature here, they are the business model. You will not have to explain the value. Two of these also tend to be funded by a budget rather than a margin, which makes the annual conversation easier than it is with a café counting cups.

Who to turn down, and why it is a favour

Saying no early is not lost revenue. These projects end badly, slowly, and usually with a refund request and a review you did not want.

The once-in-a-lifetime trades. Wedding venues, conveyancers, driveway contractors, funeral directors, double glazing. The work is often excellent and the owners are often lovely. Nobody keeps the app.
The five-page brochure. Company history, a team photo, a contact form. Wrapped in an app it becomes a product with nothing to do, and that is the most common reason these projects are rejected by review under guideline 4.2. The rejection is not a technicality; the reviewer is noticing the same emptiness the customer would.
The business with no digital habit. No site worth the name, no mailing list, a Facebook page as the entire presence. An app is not the missing piece, and the retainer will quietly turn into unpaid training.
Anything that needs the hardware. Background location tracking, Bluetooth equipment, offline-first field work, continuous sensors. Find out where the line actually sits before you promise anything — the difference between a native screen and a wrapped page is precisely the difference between a yes and a refund.
Anyone who thinks the app will bring customers. It will not. An app is a retention tool; it works on the audience a business already has. Somebody with no audience is buying the wrong product, and by month two it will be your fault.

That last one deserves saying out loud on the call, even though it costs you sales. The client who hears it and still signs is the client who stays.

Two minutes at your desk, before you ever call

Every one of these is checkable without speaking to anybody.

Open their site on your own phone. Not a desktop browser squeezed narrow — an actual phone. If it is painful to use, that pain is what you would be shipping.
Look for the moving part. A booking widget, a shop, a timetable, a feed of posts. That thing is what the app is going to be. No moving part, no app.
Check whether they already court repeat custom. A newsletter signup, a loyalty card, a members' area. If yes, they already believe in retention and you are selling a better version of something they are already paying for.
Search both app stores for their name. An abandoned app from 2019 is one of the best leads in this business. Somebody there has already signed off on the idea once, already has the developer accounts, and already knows the thing they bought was too expensive and too slow to update.
Find out who owns the decision. An owner-operator can say yes over coffee. A franchise means head office, a committee and a brand manual — the same money, six months later, if at all.

Pick one of the four and stay there

Choose a single lane — schedules, baskets, queues or audiences — and work it until you have three or four clients in it. Not because focus is a virtue, but because of what happens to the cost of the second sale.

By the second client in the same lane you already have the demo app, the screenshots, the pricing conversation, and answers to the four objections that always come up. By the fourth, prospects start mentioning that they have seen your work at a place down the road. A gym, a solicitor and a bakery as your first three clients means paying the cost of the first client three times over and arriving nowhere.

Build the demo before the first call. Not a slide deck — a real app, in their lane, with plausible branding, that the prospect can install on their own phone while you are sitting in front of them. Everything you would have spent an hour explaining becomes self-evident in about ten seconds.

Then what

Once somebody says yes, the next question is what to charge, and there is a floor below which this business does not work — that is in what to charge a small business for their app. The shape of the business as a whole, including the thing that breaks once you pass about forty clients, is in selling apps to local businesses. And if you are still deciding whether to run this at all, the case for starting now rather than next year is in how to start an AI app-building business.