A website gets you found. A web app does a job in the browser. A native app lives on the phone and can use everything the phone can do. Most businesses need the first, many could use the second, and fewer than they think need the third.
We build all three, and our own two products made opposite choices for good reasons. Here is how to tell which one your project needs.
The three options in plain terms
A website is pages people read: your services, your work, your prices, your contact form. Its main job is to be found on Google and in AI answers, and to turn visitors into enquiries.
A web app runs in the browser but behaves like software: people sign in, enter data, and get something done. Nothing to install. You send a link, or a QR code, and they're using it.
A native app is built for iPhone and Android and installed from the App Store or Google Play. It can run in the background, work fully offline, and use the camera, sensors and notifications without restrictions.
Side by side
| Website | Web app | Native app | |
|---|---|---|---|
| Found on Google | Yes, that's its job | Its public pages, yes | Only through its store listing and website |
| Install needed | No | No; can be added to the home screen | Yes, from a store |
| Works offline | No | Partly, if built for it | Yes |
| Notifications | No | Yes, with limits; on iPhone only once added to the home screen | Yes, fully |
| Updates | Instant | Instant | Through store review |
| Store fees | None | None | Apple: 99 USD a year. Google Play: 25 USD once |
| Relative cost to build | Lowest | Middle | Highest, often two platforms |
How our own products decided
PixelScore went web app
PixelScore is a scoreboard for game nights: quick matches, tournaments and leagues. The moment that matters is someone at a table saying “let's keep score,” and four people joining in seconds. Asking each of them to find and install an app first would kill that moment. A web app opened from a link or a QR code removes the install entirely, and updates reach every player instantly.
SyncPill went native
SyncPill is a pill checklist for an older parent that alerts the family when a dose is missed. Its reminders have to ring on time, every time, even with no internet connection, on a phone owned by someone who will never troubleshoot a browser setting. That reliability requires a native app on both stores.
Same studio, opposite answers, because the products needed different things.
A quick way to decide
Ask these in order. The first “yes” usually settles it.
- Is the main goal to be found and get enquiries? You need a website. Start there even if an app comes later.
- Must it work reliably with no internet, or run in the background? That points to a native app.
- Does it depend on dependable notifications, especially on iPhone? Native, unless users will reliably add your web app to their home screen.
- Do people use it occasionally, or together, or on a shared link? A web app removes the install step that loses people.
- Do you need to update it often and quickly? A web app ships changes the moment they're ready.
- Will people open it every day, like a habit? A native app's home screen icon earns its keep.
Three expensive mistakes
Building an app before a website. An app with no website behind it is hard to find and hard to trust. The website is how people discover the app.
Going native for features nobody uses daily. If people will open it twice a month, the install step and the two-platform build cost more than they return. A web app may do the job for a fraction of the price.
Forgetting the stores are a process. Native apps go through review on every update, and a first Android launch on a new personal developer account includes a mandatory 14-day closed test. Budget the time. Our first-launch checklist covers it step by step.
Sources
- Choosing a membership, Apple Developer (program fee)
- The Apple Developer Program: cost, setup and what you get, Adalo (Google Play registration fee)
- App testing requirements for new personal developer accounts, Google Play Console Help