The email says "we need an app." Sometimes that means iOS and Android, push, a job that lives in a pocket. Sometimes it means the website, squeezed into a wrapper, submitted to two stores. Do you need a mobile app, or is the website enough? That split has to be named before anyone quotes the stores.
I build this as mobile apps, usually as the same product as the website or the SaaS — not a second team. The brief I write before I quoteis where "app" either becomes a phone job, or gets cut. If you haven't named whether it's a website or a web product, stop. A brochure does not need an icon.
What most mobile app briefs actually mean
They mean a home-screen icon. A competitor has one. An investor asked if it's in the App Store. The thing underneath might be five marketing pages, a live product people already use in a browser, or an idea. The brief does not change: put it on a phone.
On a phone is not the same as an app. A fast site already runs on a phone. Wrapping that site and calling it native is how you pay for signing, listings, and a review that often fails — then the people who install it get the same pages, slower, with an extra chrome they did not ask for.
I have shipped the other shape. The local news app is a phone job: location, realtime, push, then the stores — because readers check nearby stories, not because someone wanted an icon. That work sits in selected work. The pattern is the same. The store listing is not the product. The job on the device is.
When the website is enough
Most of the time it is. This is the boring answer, and it is how you avoid a six-month store project for a contact form. A website is enough when the phone is just where the stranger happens to be.
- 01
The useful thing happens once
Read, call, book, buy. Nobody opens it tomorrow to do the same job. A site on a phone is the whole product. An app they install once and forget is a listing you now have to keep approved.
- 02
The browser already does the job
Safari and Chrome on a phone are fine for a fast site. If the complaint is "it feels like a website," the fix is usually speed and layout — not two store accounts.
- 03
Nothing on the device is required
No push they would actually tap. No camera, no maps they live in, no offline shift. If the phone is just a smaller screen, build the smaller screen.
Make the site excellent on a small screen instead. That is the website work: speed, the tap target, the next step without a login they will never create. If the site is slow, an app will not forgive it — a slow website is a product problem, not a reason to wrap it. It will package the slowness.
When you actually need a mobile app
Three things, usually together. One of them is not enough. This is the same cut as what belongs in a first version — a named person, a job that completes — applied to a pocket instead of a URL.
- 01
They come back on a phone, not a laptop
Drivers, field staff, readers checking twice a day. The job lives in a pocket. A bookmark to a dashboard they open on a monitor is not that.
- 02
A notification has to do real work
The story is nearby. The order changed. The route moved. If they would miss it in email, push is part of the product. A marketing ping is not a reason to ship an app.
- 03
The phone can do something the site cannot
Location while they walk. Camera into a workflow. A gesture that is miserable in a browser tab. If you cannot name that, you want an icon on the home screen. That is vanity.
iOS and Android from one codebase, same accounts as the web product, stores as part of shipping — that is what I own on this kind of job. I do not hand you an IPA. I do not start a second backend so the app can have its own personality.
Website
The phone is a smaller screen
Explain, convert, maybe a login in the browser. No store required.
Mobile app
The job lives in a pocket
Return visits on a phone, a device capability, a store listing that is earned.
When the mobile app should wait
I will say so. Pretending every product needs the stores is how you burn a quarter before anyone uses the thing. These are the cases where the honest first move is a site, a web product, or taking over what already runs — not TestFlight.
- 01
Nobody returns to the web product yet
Stores after a product someone already uses. Starting in TestFlight is two review queues before you know if the job is right. Ship the URL. Watch who actually comes back on a phone.
- 02
You needed a website
Five pages and a form, wrapped and submitted to Apple. You pay app money for brochure work, then fail review because there is nothing to do inside. Rank. Convert. Then ask again.
- 03
The brief is a second product
New API, new accounts, new admin "for mobile." That is two companies. The app sits on the same auth and data as the site or the SaaS — or you don't start.
If a website would do the job, I ship the website. An icon is not a strategy. It is a distribution channel with a review queue.
If you're staring at a brief that only says app, send the job in a sentence instead — tell me what you're building. The rest of website or app is that sentence from different angles.
