Almost every page answering this question gives you a table: simple app $20,000 to $50,000, complex app $150,000 and up. The table is useless, because the number it produces is engineering weeks multiplied by a rate, and the ranges are wide enough to contain every possible answer. What is worth knowing is which parts of an app consume the weeks, because that is the part you control.
Cost is weeks times rate, and only one of them is about Flutter
A quote is the number of engineering weeks a build takes multiplied by what an engineer costs. Flutter affects the first number, because one codebase produces both platforms. It does not affect the second, which is set by who you hire and where they are, and which varies by a factor of five or more across the market for the same work.
This is why published cost tables disagree so violently. A page written by a European agency and a page written by an offshore studio can describe the same app and land four times apart, and both can be telling the truth about their own costs. Neither tells you anything about your app.
So the useful question is not what an app costs. It is how many weeks of work your app contains, and where those weeks go. Get that right and you can price it against any rate you are quoted, and you can tell an inflated estimate from an honest one.
What Flutter genuinely saves, and what it does not
The saving is real but narrower than it is sold as: one codebase means UI, business logic and state are written once instead of twice. It does not make the platform-specific work disappear, and on most apps that work is a meaningful fraction of the total.
Written once: screens, navigation, state management, networking, local storage, and the great majority of feature logic. Against two native codebases this is the bulk of a build, and it is where the cross-platform argument is won.
Still done twice, or done once but per-platform: push notification setup, in-app purchase configuration on both stores, deep links, permissions dialogue copy, background execution, and anything touching a native SDK without a maintained plugin. Signing, provisioning and store submission are also per-platform and are not shared.
A reasonable planning assumption is that Flutter removes most but not all of the second platform's cost. Treating it as a straight fifty per cent saving overstates it, and any estimate built on that assumption will run over on the release work specifically.
The five things that actually move the number
In practice, five decisions account for most of the variance between a cheap build and an expensive one: whether there are user accounts, whether there is a backend, whether money changes hands, whether anything happens in real time, and whether the app has to work offline.
Accounts. Sign-in, password reset, session handling, and — because both stores now require it — in-app account deletion that genuinely deletes rather than deactivates. The deletion path is cheap when you build it alongside sign-in and expensive when you retro-fit it into a schema that assumed accounts were permanent.
A backend. If your app needs data that is not on the device, someone is building and running a server, and that cost sits outside the app estimate entirely. Apps that can be answered by a device-local database and a third-party API are dramatically cheaper than apps that cannot.
Payments. A subscription or purchase means store billing on both platforms, receipt validation, restore-purchases, and a paywall that survives review. This is a well-trodden path with good tooling, but it is never a one-week item, and treating it as one is a common source of overrun.
Real time. Chat, presence, live location or anything that pushes rather than polls brings sockets, reconnection logic, and a whole class of state bugs that only appear on flaky mobile networks. It is the single largest step change in this list.
Offline. Working without a connection means a local source of truth, a sync strategy and a conflict rule. It is often requested casually and it is never cheap.
The line items estimates leave out
Most overruns are not the features. They are the work that everyone knows about and nobody puts in the estimate: release, review, devices, and the weeks after launch.
Release is its own body of work. Store listings, screenshots, privacy declarations, signing, and the review cycle itself. App Review rejections cluster around a small and stable set of guidelines — external payment steering, missing account deletion, paywalls without terms links, and duplicate-app findings for studios shipping several apps from one codebase. Every one of them is decided by design choices made weeks earlier, which is why they are cheap to design around and expensive to discover at submission.
Devices. Android fragmentation is real, and so is the range of iPhone sizes still in use. Testing across it is a line item, not a rounding error.
The month after launch. Crash reports arrive from hardware you did not test on, and the first real users find the paths your test data never covered. Budget for it explicitly; an estimate that ends at submission is describing something other than a shipped product.
Maintenance after that. Both platforms ship an OS version every year, each with SDK requirements that eventually become mandatory. An app nobody maintains does not stay still — it stops being installable.
One engineer or an agency, and where each actually wins
The saving from hiring one engineer is not the rate. It is the rework you do not pay for later, and the absence of a translation layer between the person deciding and the person typing. The agency wins on scale, and the honest answer depends on which of those your project needs.
Most of what I get called in to fix is an app that was built cheaply, shipped, and then cost more to stabilise than it did to write in the first place — memory leaks, no state management layer, an API called four times where once would do. On one such engagement, refactoring to Clean Architecture with BLoC rather than patching symptoms cut unnecessary API calls by around 40% and improved performance and stability by around 70%, in four weeks. That is four weeks that would not have been spent if the architecture had been right the first time, and it is the real cost of the cheap bid.
Where an agency genuinely wins is scale: several engineers in parallel, a project manager, a design team. If that is the shape of your project, hire the agency — one senior engineer is the wrong tool for it, and I will say so on the call.
For a single well-scoped product, though, the ownership is the point. In 2026 I built and released five iOS apps as the only engineer, each one taken from an empty repository through App Review to the store, so I am describing that scope from having done it rather than from having estimated it.
How to read a quote you have been given
Ask for the estimate broken into engineering weeks per area rather than one total, and check that release, testing and the first month after launch appear as their own lines. An estimate that cannot be decomposed is a guess with a decimal point on it.
Then check the five drivers above against what is written down. If the app has accounts, payments and real-time features but the estimate is flat across them, whoever wrote it has not thought about it — those areas do not cost the same and an estimate that says they do is not an estimate.
Ask what happens when a scope change arrives mid-build, because one will. The answer tells you more about what the engagement will actually cost than the headline figure does.
I quote per engagement rather than publishing a single hourly figure, because the rate genuinely depends on duration and scope. What I will do on a first call is decompose your app into the areas above and tell you which ones are expensive, whether or not you end up working with me.
Originally published at shahryarahmad.com.
Top comments (0)