Mobile App or Web App? When to Build an App and When Not To

Build a mobile app when people will open your product several times a week and need something a browser does badly on a phone: instant alerts, the camera all day, location in the background, Bluetooth or offline use. If they come a few times a month to get a task done, start with a web app. It costs less to build, you can change it the same day, and people find it through Google instead of an app store.

There’s a middle path too. A web app can sit on the phone’s home screen like an app (a progressive web app, or PWA). If you write it in Flutter, as we did for Daisy’s Guide, the same code can become iPhone and Android apps later.

App or web: the short answer

Question	Points to a mobile app	Points to a web app
How often does one person use it?	Several times a week or every day	A few times a month or less
Where are they when they use it?	On their feet, between other tasks	At a desk, with time to read
What does the main job need from the phone?	Background location, Bluetooth, NFC, offline mode, heavy camera use	Forms, lists, search, payments, dashboards
How do new users find you?	They’re your existing customers, invited from inside the product	Google search, ads and links to a page
What do the screens look like?	One main action per screen	Big tables, editors, many panels open at once
How fast must changes go live?	You can wait for store review on each release	You want to ship a fix the same day

If most answers land in the right column, start on the web. If two or more land on the left, and one of them is the main job, plan an app.

Five questions to answer before you pay for an app

1. How often will one person open it? An app earns its place on the home screen through repeat use. If people will use it once to book something and then forget it, a website does that job without asking anyone to install anything.
2. Does the main job happen away from a desk? Traza’s tattoo artists were already taking real bookings on the Traza website. But they spend the day on their feet, between clients, and need to answer requests and take deposits from the phone. That’s why Traza asked for an artist app.
3. Which phone feature can’t you do without? Check the list against what the main job needs, not what would be nice. FlyDesk’s app uses an NFC scanner to track where people work and lets them check in to a coworking space. A browser can’t do that well, though a booking form works fine in one.
4. How will the first 100 users find it? If your plan depends on Google search, ads or links you share, people land on a web page first. Asking them to install an app before they see anything useful adds a step where some of them leave.
5. Can you run two release tracks? Every app update goes through store review. You also need developer accounts and someone who answers review feedback. A web app ships when you press deploy.

What a browser can do on a phone today

Web apps can do a lot on phones. They can use the camera, show the user’s location while the page is open, take card payments and live as an icon on the home screen.

For years, push notifications on iPhone needed an app. Since iOS and iPadOS 16.4, web apps added to the Home Screen can send push notifications, as long as the user grants permission right after tapping something in the app, such as a subscribe button. The user still has to add your web app to the Home Screen first, so you have to show them how.

The browser still falls short for work in the background, like tracking a walk while the phone sits in a pocket, and for Bluetooth or NFC hardware. Offline use is possible on the web, but it’s harder to get right than in an app.

The middle path: a web app that installs like an app

Daisy’s Guide helps couples get ready for their first child. It started as a printed guidebook that sold well, and the founders wanted the same guide as an app. The budget was small.

We built the first version as a web app that couples add to their phone’s home screen. It’s written in Flutter, runs on Supabase, and one Stripe payment unlocks the whole guide. It reached a beta with real couples about 2 months after kickoff. The same Flutter code can be built into iPhone and Android apps later. Publishing to the stores was priced as a separate add-on and wasn’t part of the first project, and after the first version the client chose a different direction, so the app stayed a web app. The Daisy’s Guide case study has the full scope.

This path suits a product people come back to, as long as it doesn’t need background location or hardware. You test the idea without store review, and you keep the code if the stores become worth it.

When the app is the right call

Traza is an Australian marketplace for tattoo artists. Its website worked, but artists needed to answer requests, plan sessions, take deposits and reply to messages between clients. Our React Native team built the artist app on Traza’s live API and its existing designs, with push notifications for new requests, messages and session changes, and Instagram login, because that’s where artists already show their work. The App Store and Google Play approved it, and it went live in early 2026 (Traza case study).

Traza started with one side. The artists, who work from their phones, got the app first, and a second phase for the client side was scoped after that.

What the app stores add to your plan

Item	What it involves
Apple Developer Program	$99 a year
Google Play developer account	US$25, paid once
App Review	Apple says it reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. A rejection means a fix and another round.
Minimum functionality	Apple’s guideline 4.2 asks for features, content and UI that go beyond a repackaged website. A website in an app wrapper risks rejection.
Digital purchases	Unlocking features or premium content in an iPhone app has to go through Apple’s in-app purchase (guideline 3.1.1). Physical goods and real-world services are paid by card or Apple Pay instead (3.1.3(e)).
Every update	Goes through review again, so plan releases around review time.
Tooling deadlines on iPhone	Since 28 April 2026, apps uploaded to Apple must be built with Xcode 26 or later and the iOS 26 SDK.
Tooling deadlines on Android	From 31 August 2026, new apps and app updates on Google Play must target Android 16 (API level 36).

Rejections are a normal part of this. In 2025 Apple reviewed 9,100,620 submissions, rejected 2,093,244 of them and later approved 387,087 that had been rejected (App Store Transparency Report 2025). The tooling deadlines come every year too, so an app needs someone to update it even when you aren’t adding features.

Payment rules also differ by country. Apple’s current guidelines allow apps on the United States storefront to include buttons or links that lead to buying outside in-app purchase (3.1.1(a)). In every other storefront they still don’t.

On Traza the launch date was fixed, so we sent the app to review early instead of polishing it until the last day. Both stores approved it.

What it costs with us

A first version of a web or mobile app typically costs $5,000 to $15,000 with us and takes 2 to 4 weeks. For an app, store review comes on top. To see what each version costs to build, run the same brief through our project estimate twice, once as a web app and once as a store app. It turns the brief into user stories, you confirm what is in scope, and we multiply the hours by our published rate of $39-55 an hour after checking them against what our team actually books on finished projects. The gap between the two budgets is what the store app adds. Both are planning ranges, not fixed quotes. One React Native or Flutter app covers both iPhone and Android, and after launch the work continues at $39 to $55 an hour.

Still unsure which way to go? A 1-week discovery sprint costs a fixed $3,000. It ends with a written scope, a clickable prototype of the main screens and a fixed price for the build, and the $3,000 counts toward the build if you build with us. Our mobile app development and web app development pages show what each service includes.

What we would do

1. Write down how often a typical user will open the product in a week, and where they’ll be when they do.
2. List the phone features the main job needs. If none of them is background location, Bluetooth, NFC or heavy offline use, plan a web app.
3. Build the first version as a web app people can add to the home screen. If you expect to need store apps later, write it in Flutter so the code carries over.
4. Track weekly return visits and how many users add the app to their home screen.
5. Build the store app when repeat use or a phone feature makes it pay off. Start with the side of your product that works from the phone, as Traza did.
6. When you do, open the Apple and Google developer accounts early and send the first build to review well before launch day.

FAQ

Should a startup build a mobile app or a web app first?

Start with a web app unless users will open the product several times a week away from a desk, or the main job needs background location, Bluetooth, NFC or offline use. A web app is cheaper to change and easier to find through search.

Can a web app send push notifications on iPhone?

Yes, since iOS and iPadOS 16.4, if the user has added the web app to the Home Screen and grants permission after tapping a button in it. A web page open in a regular Safari tab can’t.

How much does it cost to publish an app on the App Store and Google Play?

Apple’s developer program costs $99 a year, and a Google Play developer account costs US$25 once. Building the app costs far more: with us, a first version typically costs $5,000 to $15,000.

Will Apple accept an app that just wraps my website?

Probably not. Apple’s guideline 4.2 says an app should include features, content and UI that go beyond a repackaged website. If the app adds nothing to the site, keep the site.

Do I need separate apps for iPhone and Android?

Usually not. One React Native or Flutter app runs on both and goes through both stores. We write native Swift apps when an iPhone-only feature needs it.