11App developmentEveryday toolsA way of working
The app factory
One way of working for building small paid apps in waves: research on real store data, spec, design, one codebase for both platforms, and full testing before every release.
Two in development, two prototypes, one at the spec stage
The challenge
Almost every app store category is already held by free apps with in app purchases that are active and highly rated. A good idea is not enough; you have to find the exact gap. On top of that, Apple and Google are particularly wary of anyone submitting many small apps from one account. That is precisely the pattern their rules were written against, and the risk is not one rejected app but the whole account.
What I did
- Started from data, not ideas. In the first round I produced 113 ideas across 11 niches, from 333 searches of store data and the reviews of 22 leading apps. Each idea got a weighted score: demand, weakness of the leaders, money, ease of building, differentiation and store risk. When the leaders are strong and active, an idea goes to the backlog even with a high score.
- Built differentiation out of real complaints. The gaps turned up in specific places: a leader that hadn't been updated in years, a paywall in the middle of use, a subscription where people expect to pay once. That set the pricing principle: free to download, a one time purchase by default, and a subscription only where there is a real, ongoing cost.
- Set one toolkit for every app. One codebase for iPhone and Android, my own server with permissions on every table, a separate code repository per app, development and production environments, and a decision log for each app. Sharing between users goes only through the server, because Apple only or Google only solutions don't work across both platforms.
- Filtered for store risk before writing code. Every app is reviewed against Apple's and Google's guidelines before submission, with a checklist of rejection reasons that grows from app to app. Categories Apple explicitly flags, such as drinking games, don't get in at all.
- Full testing before every release. Every feature, in every language, on iPhone and Android, including two devices sharing the same data, iPhone against Android too. And no cloud build until I've seen on my own machine that it looks right.
The decision that made the difference
Every app gets its own design language and its own value, not one skeleton in different colors. A factory that clones a template is exactly what Apple's rules against similar apps aim at. So each app starts from its own references and design directions, and in the medication app I turned down a design direction partly because of the risk it would look like other apps in the factory. The cost is more work per app. The gain is a factory that doesn't look like the pattern those rules were written against.
The apps
Nickelby, an allowance ledger for parents
Stage: testing ahead of store submission. Full case: Nickelby.
Medication reminder with a safety net
Stage: development. Full case: A medication reminder with a safety net.
Stubbo, a subscription tracker
Stage: spec and prototype. Tracks every recurring charge, with a reminder before each one. In reviews of the category leader, alerts fail on exactly the annual charges, and the new competitors demand a subscription or a bank connection. The call: no bank, up to 5 subscriptions free including alerts and a monthly and yearly summary in shekels and dollars, and a one time unlock for the sixth subscription and up, the widget, export and a reminder before a free trial turns into a charge. The paywall message: the app pays for itself with the first subscription you remember to cancel. A receipt inspired design direction. The prototype runs, and every screen was captured in Hebrew and English, in light and dark mode.
The household pet app
Stage: spec and prototype. Waiting on a design direction, name and price. One shared app for everyone in the house: "fed" and "walked" with a single tap, so nobody argues over whether the dog has eaten, and a vaccination file that produces a PDF the moment a kennel or vet asks for it. The long standing leader in the space hasn't been updated in years and users complain their records were deleted, so the core promise is that records don't disappear. The prototype keeps everything on the phone and works offline. Sync between household members is planned as a separate layer and hasn't been built yet. Three design directions are ready to choose from.
Twins
Stage: spec. The research recommended against a separate twins app, suggesting twins be folded into a general baby app. I decided to build it anyway after a parent of twins told me "everything" was missing: one screen for both, fast logging for both, growth comparison, and sync with a partner. A real user's testimony outweighs a score built from reviews. The spec: birth to one year, up to three babies, each baby against their own growth curve side by side, never marking who is ahead or behind, corrected age for preemies by default, free for one parent and paid per additional connected person.
Outcome
- Five apps at documented stages: two in development and testing, two with a working prototype, one with a full spec.
- A fixed way of working that applies to every new app: toolkit, security rules, a store guideline review, and a full test round before any release.
- None of the apps is in a store yet.