Every client app I scope starts the same way. Before anything the customer would recognize as their app exists, I'm building sign-in and roles, push notifications, a settings screen, a branding layer, a small backend, and some way for the owner to see what's going on. It's necessary. It's identical from one job to the next. And the client never pays for it separately, because to them it's just "the app."
So I'm building it once. I'm calling it IosShell
What it is
IosShell is a SwiftUI starter shell: a chassis of the pieces every app needs, plus swappable modules for the features that differ from one business to the next. When a project starts, I pick the parts it needs, delete the rest, and put my time into the work that's actually specific to that client.
It is not a product I'm selling. It's delivery infrastructure for my own client work. That matters, because it changes the question. I'm not asking whether anyone would buy a starter kit. I'm asking whether it makes my projects cheaper to deliver than they are today.
Who it's for
Small local businesses with repeat customers: studios, salons, gyms, clubs. The owner wants an app under their own name, and today they're choosing between two imperfect options. A no-code builder is fast and cheap, but the result looks like everyone else's and the logic is limited. A fully custom build is distinct, but it costs a lot and takes months.
I'm aiming at the space in between: native, custom where it matters, and delivered in weeks.
The math
I don't trust a plan until it has a number on it, so here is the number.
I estimated each component from scratch, at my billing rate of $100 an hour. Branding, settings, push, auth and roles, the backend, an admin view, and a loyalty and membership module come to 328 hours. That's roughly $32,800 of my time.
If a project reuses 70% of that code, it saves about 230 hours, or $23,000. Divide 328 by 230 and you get 1.4. The shell pays for itself on the second project.
I should be plain about what that is. Every input is my own estimate. No client has looked at these prices. The 70% reuse figure is a target, not a measurement. The math tells me what has to be true. It doesn't tell me that it is.
What would prove me wrong
My background is in project management, and the habit that stuck is writing down what failure looks like before I start. So here it is.
I'll take the loyalty and membership module, since it's the closest to finished, and pitch it to real prospects. The idea is validated if I sign three paid client engagements within 90 days, each with at least 70% of its code coming from the shell. If I sign fewer than three, I stop building modules and reassess.
I also don't have category-level demand data. What I have is vendor and agency sources that list booking, loyalty and field-service apps among the most requested small-business builds. That tells me what vendors market, not what buyers pay for. I'd rather say that now than discover it in month four.
Two constraints I'm planning around
**Apple's template rules.** Apple's guidelines expect apps built from a template to be submitted by the business itself. So each app ships under the client's own developer account, and I customize enough that each one is clearly its own app. I'll confirm the current wording before I price anything.
**Scope.** The first build is the chassis and one module. Booking, quotes and jobs, ordering and employee tools all wait until the test passes. They're good ideas, and that's exactly why they're dangerous.
What's next
I'll keep writing as this goes: how the chassis is structured, what the quick-start check looks like in practice, and what happens when the first real prospect reads the price list.
If you run a small business and you've been wondering whether a native app is within reach, I'd like to hear what you'd want it to do. You can reach me at [email protected].
*Jeanese Latiolais builds native iOS apps in SwiftUI and has spent roughly thirty years in software development and program management.*
