Flutter vs two native apps: the honest math for a local business
One shared codebase or separate iPhone and Android apps? For most local businesses the answer is clear once you add up three years of cost.
Sooner or later every owner who wants an app gets two quotes that look nothing alike. One shop wants to build an iPhone app and an Android app separately. Another wants to build once with Flutter and ship to both. The gap between the quotes can be the price of a service van.
- For booking, loyalty and ordering apps, one Flutter codebase does the job at roughly 55–65% of the cost.
- The savings grow after launch, because every fix and feature is built once.
- Native still wins for a short list of cases. Most local businesses are not on it.
What the two options actually are
Native means two separate apps. One is written for iPhone, the other for Android, usually by different developers. Each uses the tools the phone maker provides, so it has first access to everything the phone can do.
Flutter is a toolkit that lets a team write the app once and publish it to both stores. Your customers cannot tell the difference. The app installs from the store, sends push notifications, takes wallet payments, uses the camera and the map.
The question is whether what you give up with one codebase matters for your business.
The math over three years
Build cost gets all the attention, but an app is a three-year commitment at minimum. Phones get new system versions every year, your services change, and customers find bugs. Here is a typical range for a booking-and-loyalty app in our projects.
| Cost | Two native apps | One Flutter app |
|---|---|---|
| Initial build | $60,000–$90,000 | $35,000–$55,000 |
| Yearly maintenance | $12,000–$18,000 | $6,000–$10,000 |
| Each new feature | Built and tested twice | Built once |
| Three-year total | $96,000–$144,000 | $53,000–$85,000 |
The yearly line is where owners get surprised. With two apps, a change to your booking flow is two projects with two rounds of testing, and the apps drift apart. One has the new reschedule button and the other gets it next month. Your front desk ends up asking callers which phone they have.
- 40% lower three-year cost with one codebase
- 10–14 weeks typical build for a booking app
- 1 team to call when something breaks
Where native still wins
Flutter is not the answer to everything. Go native, or at least get a second opinion, if your app depends on any of these.
- Heavy use of phone hardware: connecting to diagnostic tools over wireless, advanced camera work, augmented reality.
- Deep ties into the phone itself, such as elaborate home-screen widgets or a watch app as the main product.
- An app that only one platform's users will ever use, like a tablet tool for your own technicians. Then one native app is simply one app.
- An existing native app in good shape with a developer who knows it. Rewriting working software rarely pays.
For a customer-facing app that books appointments, shows order status, holds a punch card and sends reminders, none of these apply.
The app your customers need is a short list of ordinary features done well. Ordinary features do not need two codebases.
What customers notice, and what they do not
We have shipped both kinds. Customers do not notice which toolkit built the app. They notice four things: whether it opens fast, whether booking is quick, whether it remembers them, and whether it crashes.
All four depend on the care of the team, not the framework. A sloppy Flutter app is slow. A sloppy native app is slow twice. BrightSmile Dental's patient app runs on a single codebase, and the feedback we hear about it is about reminders and reschedule links, never about how it was built.
Whichever route you choose, make sure the store accounts and the source code are in your company's name. An app you cannot move to another developer is a lease, not an asset.
Questions to ask before you sign
A quote tells you little without these answers.
- What is the yearly cost to keep the app current after launch, in writing?
- Who owns the code and the store listings?
- How long does a small change take to reach both platforms?
- Which of my features, specifically, would need native code, and why?
If a shop recommends two native apps and cannot give a concrete answer to the fourth question, you are paying for their preference. Our mobile apps page shows what we build and how, and pricing gives you a range to compare against.
Do this week
Write down the five things your customers would do in an app, in plain words: book, reschedule, pay, check status, get reminders. Check the list against the native-only cases above. If none match, ask every bidder for a three-year total on a single-codebase build, including maintenance, and compare those totals instead of the build price.
