We build mobile apps. We are still going to tell you that most businesses asking this question should not build one.
Short answer: If customers interact with you a few times a year, you need a fast mobile website, not an app. Build an app when you need repeat usage, device features a browser cannot reach, or offline access. The deciding factor is almost never the build - it is whether you can get anyone to install it and keep it.
The three-question test
Answer these honestly before anyone quotes you a number.
1. How often does a customer need you? Daily or weekly usage justifies an icon on a home screen. A few times a year does not. Nobody installs an app to book one appointment - they will use your website and uninstall the app the same afternoon.
2. Do you need something a browser cannot do? Push notifications, camera and barcode scanning, GPS in the background, Bluetooth hardware, offline data capture. If none of these are on your list, a well-built mobile site does the same job with no install friction.
3. Do you have a reason for someone to open it a second time? This is the one that kills most app projects. A brochure in app form gets opened once. Loyalty balances, order tracking, saved progress, scheduled content, account data - these bring people back. A list of your services does not.
Two or three yeses: an app may be right. One or fewer: put the budget into your website and your acquisition, and you will make more money.
What most people underestimate: nobody will find it
This is the part that gets skipped in every "should we build an app" conversation, and it is the part that decides whether the project earns anything.
Building the app is the predictable half. Distribution is the hard half, and it does not start until you ship.
We launched an Android app of our own build - AI For Everyone - and tracked the whole curve in Play Console:
| Period | What happened |
|---|---|
| Months 1-2 | Zero installs, zero store traffic. Live and invisible. |
| Month 3 | First installs, almost all from Play's browse surfaces |
| Month 4 | First real ramp |
| Months 5-9 | Play search finally contributes; volume compounds to ~57 installs/week |
The lesson for anyone weighing an app: a finished app with no distribution earns nothing, and the store will not hand you distribution until you prove people keep using it. If your app has no reason to be opened twice, it will never clear that bar. Which brings you right back to question three.
Realistic cost and timeline
Ranges we see for well-run projects with a responsive client and clear scope. Complexity, integrations, and approvals push you to the top of each band.
| Project | Timeline | What drives it |
|---|---|---|
| Mobile-optimized website | 2-6 weeks | Content, design, one integration |
| Progressive web app (PWA) | 4-10 weeks | Offline behaviour, installability, push |
| Single-platform app (MVP) | 3-6 months | Core features, accounts, data, QA, store review |
| Cross-platform app (iOS + Android) | 4-8 months | Two store processes, device matrix |
| Complex or regulated app | 6-12+ months | Compliance, security, integrations |
- Ongoing maintenance. iOS and Android ship breaking OS updates every year. An unmaintained app degrades and eventually gets delisted. Budget for it annually, not once.
- Getting installs. The store is not a distribution channel you get for free. Listing optimization, screenshots, ratings management, and retention work are continuous, and they are what determines whether the build ever pays back. You can do this without an ad budget - we did - but you cannot do it without the work.
The middle option most people skip
Between "mobile website" and "native app" sits the progressive web app. A PWA installs to the home screen, works offline, and can send push notifications on both major platforms - without an app store, a review process, or a separate codebase per platform.
It is the right answer more often than it gets chosen, especially when the honest reason you want an app is "I want an icon on their phone." You can have the icon without the store.
What a PWA still cannot do well: heavy device integration, background location, tight hardware pairing, and anything where store presence itself is the point.
When an app genuinely is the answer
Clear yeses, from the pattern of projects that work:
- Repeat-transaction businesses - restaurants with loyalty and reorder, gyms with class booking and check-in
- Field and operations tools - technicians capturing jobs, photos, and signatures offline, syncing later
- Products with saved state - anything where progress, history, or an account is the reason to return
- Hardware-adjacent products - Bluetooth devices, scanning, sensors
- Products where the app is the product, not a channel for something else
What to ask before you sign
- What does a user do on day 2, day 7, and day 30? (If there is no answer, stop here.)
- Would a PWA meet the requirement, and if not, precisely which requirement rules it out?
- What is in the maintenance contract after launch, and what does a year cost?
- Who owns the developer account and the source code? (You should.)
- What is the plan for installs - listing optimization, screenshots, ratings - and who does it?
- How will we measure retention, and what number means this is working?
We build Android and cross-platform apps, and we run the store optimization behind them. If you want a straight answer about whether your idea justifies an app, tell us what you have in mind - the answer is free, and sometimes it is no.
