Installable web app (PWA)
Validating an idea; content and forms, no deep device access
$0 + domain · Low
△ You need push on every platform, background work, or a store listing people can find
Drawing set · L0–L3
build an app
A phone app lives inside someone else's rules. The store decides whether you ship, the operating system decides when your code may run, and every update waits in a review queue. This drawing set maps the shapes an app can take, from a website that installs like an app to a native build with a backend, and when each one is worth its cost.
Design philosophy
An app is a guest in a phone it does not own. It is judged by how politely it uses the owner's battery, attention and trust.
Ask for the least
Every permission you request is a reason to uninstall. Ask at the moment it is needed, explain why, and keep working when the answer is no.
You cannot hotfix a store
A server bug is fixed in minutes; an app bug waits for review and for users to update. Put logic that changes often on a server, not in the binary.
The system is the boss
The operating system can pause, kill or sandbox you at any moment. Design for being interrupted instead of fighting the rules.
First app, one person? Start as an installable web app or a cross-platform build. Go native only when you need something the system hides from everyone else — calls, background work, sensors.
SheetL0
Prototype
Used byYou, on your own phone
Per month$0
①Why move up
You want to hold the idea in your hand and see whether you actually open it twice. No store, no users, nothing to protect.
②Architecture
Either a web app that installs to the home screen, or a cross-platform build running on your own device through a development app. No backend: data stays on the phone.
Δ New at this level
- + The app on your own phone
- + A single-screen core flow
Shapes on the map: Installable web app (PWA) · Cross-platform build (one codebase)
③Tools
Choose whatever gets a build onto your real phone fastest. The simulator lies about touch, keyboards and performance; your pocket does not.
Also worth knowing — not verified by this site
④Code and tests
- Test on a real, preferably old, phone — not only the simulator.
- Use the app for a week yourself before showing anyone.
SheetL1
Real users
Used byStrangers who installed it
Per month$0–10
①Why move up
People you have never met are installing the app on phones you have never seen. When it crashes, they will not tell you — they uninstall.
②Architecture
The app ships through the store's testing track first, then publicly. Crash reporting is built in from day one. If a system feature is essential, this is the moment to go native for that platform.
Δ New at this level
- + A store listing and testing track
- + Crash reporting
- + A signed release build made by CI
- + A privacy disclosure for the store
Shapes on the map: Cross-platform build (one codebase) · Native app (Kotlin / Swift)
③Tools
Crash reporting is not optional at this level — it is your only view into devices you do not own. Keep the signing key backed up; losing it can mean you can never update the app again.
Also worth knowing — not verified by this site
④Code and tests
- Release to a closed testing track before production, every time.
- Back up the app signing key in two places; it cannot be regenerated.
- Test the permission-denied path, not only the happy path.
SheetL2
Money and data
Used byPeople with accounts, payments and data in your app
Per month$10–50
①Why move up
Accounts, purchases or synced data have appeared. The store's payment rules now apply to you, and a data leak happens on millions of phones at once.
②Architecture
The app becomes a client of your own API. Accounts, purchases and anything that changes often move to the server, so they can be fixed without a store review. The server must accept requests from every app version still installed.
Δ New at this level
- + A backend API
- + Accounts and server-side purchase checks
- + API versioning for old app builds
- + Data deletion on request
Shapes on the map: App + backend API
③Tools
Follow the store's purchase rules exactly; many digital goods must use the store's own payment system. Verify every purchase on your server, never only in the app.
Also worth knowing — not verified by this site
④Code and tests
- Verify purchases and entitlements on the server; the app can be modified by its user.
- Keep the API backward compatible — users run old versions for months.
- Provide a working account-deletion path; stores require it.
SheetL3
Scale
Used byMany users on many devices and versions
Per month$100–1000+
①Why move up
Several versions are live at once, a bad release reaches a large audience before you notice, and the device matrix is too wide to test by hand.
②Architecture
Releases roll out in percentages with automatic halts, features ship dark behind flags you can switch from the server, and a device test farm runs on every build.
Δ New at this level
- + Staged rollouts with halt rules
- + Server-controlled feature flags
- + Automated tests on many device models
Shapes on the map: App + backend API · Native app (Kotlin / Swift)
③Tools
The goal at this level is to make every release reversible without a new build. Anything that cannot be turned off remotely is a risk you ship blind.
Also worth knowing — not verified by this site
④Code and tests
- Roll out to a small percentage first and halt automatically on crash-rate spikes.
- Ship risky features behind flags that default to off.
- Run the test suite on a matrix of real device models and OS versions.
The architecture map
Every shape this can take. Most exist so you know what not to build yet.
Cross-platform build (one codebase)
iOS and Android from one team; most everyday apps
$0–25/mo + store fees · Low–mid
△ You fight the framework to reach a system feature, or performance limits the core experience
Native app (Kotlin / Swift)
Deep system access: calls, background services, sensors — URDialer's shape
$0–25/mo + store fees · Mid — two codebases if you need both platforms
△ Accounts, sync or payments appear and the app needs a server of its own
App + backend API
Accounts, sync across devices, payments, shared data
$5–100/mo · Mid–high
△ Many releases in flight across versions — you need flags and staged rollouts
Concepts you'll actually need
One plain sentence and one metaphor each. Click any tool module for the same treatment.
- Store review
- Every release is checked by the store before users can get it; rejections usually cite a specific guideline.
- ≈ A building inspector who must sign off before each new floor opens.
- Runtime permissions
- Sensitive abilities — camera, location, calls — must be requested from the user while the app runs, and can be revoked.
- ≈ A key you have to ask for at the door, which the owner can take back any time.
- Background limits
- The system pauses or kills apps you are not looking at to save battery; work that must run later needs the system's scheduler.
- ≈ A hotel that turns off your room's power when you leave — book the wake-up call at the front desk.
- Release tracks
- Stores let you ship a build to testers or a small percentage of users before everyone.
- ≈ Opening a new dish to one table before putting it on the menu.