Powstania Warszawskiego 15
31-539 Kraków
A Flutter app is priced by its shape: a single flow with one user role, two roles with payments, or a system with a backend, an admin panel and field work. Our current price tiers for each shape are on the pricing page. This article explains what sits inside each shape, what adds weeks, and why the same scope is priced so differently depending on who is quoting it.
One kind of user doing one job: log in, see a list, open a record, act on it. Eight weeks and up. A technician checklist, a product catalogue, a booking request form that goes to a human.
A client side and a provider side that talk to each other, money moving through the app, push notifications and a first admin view. Eight to twelve weeks. Most booking and marketplace MVPs live here.
Mobile app plus backend plus web admin plus the rules of a real operation: roles, sync, reporting, integrations. Twelve to twenty two weeks. Field service, inspection and fleet products sit here.
The honest version of the Flutter pitch is narrower than the marketing version. One codebase produces the iOS app and the Android app from the same screens, the same state logic and the same tests. That means two stores shipped from one team, one bug fixed once, and one roadmap instead of two that drift apart.
On the screens and the app logic, the saving against two native teams is large.
Everything else in the budget is untouched by the framework choice. The backend and its database cost the same whether the client is Flutter or Swift. UX and UI design take the same time. Store accounts, review cycles, analytics, crash reporting and the project management around them do not care what the app is written in.
On a typical system tier project the screens and logic might be half the work. Flutter halves that half, not the whole.
This is why a Flutter quote and a native quote for the same product rarely differ by the amount people expect, and why a cheap Flutter quote is usually cheap because the scope is thinner, not because the framework is magic.
The full breakdown of the non Flutter costs is on our mobile app development cost page, and the choice between Flutter and React Native is covered on the Flutter team page.
The easiest way to see where the money goes is to take one product and grow it through the three shapes. Take a technician app for an HVAC service company, because it is the kind of product we get asked about most and because every addition shows up clearly in weeks.
A technician logs in, sees the jobs assigned for the day, opens one, reads the address and the problem description, ticks a checklist and marks the job done. The office still dispatches in its existing tool and the app reads from it. There is one user role, no payments, no offline layer beyond caching the morning's list.
This is a single flow, our entry tier, with eight weeks as the realistic floor once design and store setup are included.
Now the customer can request a visit, choose a slot, pay a call out fee in the app, and get a notification when the technician is on the way. The technician side gains photos and a signature on completion. Two roles now depend on each other, money moves through the app, and Apple will look at how that money moves.
This is shape two, our middle tier, eight to twelve weeks.
The office wants its own panel: a dispatcher view with technicians on a timeline, service contracts attached to each installed unit, versioned inspection forms, and a sync with the ERP so that a completed job becomes an invoice. Technicians work in basements and plant rooms without signal, so the app must keep working and reconcile later.
This is the system shape, our top tier, and for field service specifically it runs 10 to 22 weeks. The current numbers for all three tiers are on the pricing page.
We price this shape in detail on the field service app development cost page, and the HVAC version, with service contracts and units as records, on custom HVAC software development.
Across the projects we have delivered, four additions explain most of the distance between an entry tier quote and a system tier quote for what the buyer thinks of as "the same app". They are listed here in the order they usually appear on a first call.
A local database, a queue of pending changes, conflict rules, and a status the user trusts. A separate layer, not a setting.
Mapping your records to their ERP, CRM or field service tool, handling the cases where the API says no, and agreeing who owns the data.
A payment provider, refunds, receipts, and a design of the money flow that passes App Store review for marketplace or booking products.
A dispatcher or admin panel on the web, with its own roles and views, usually the difference between shape two and shape three.
Two of these deserve a closer look because buyers underestimate them most often.
Offline is not one feature. "It has to work offline" can mean seeing what is already there, doing work that will leave the device later, or treating the network as optional altogether, and the three versions cost very different amounts.
We wrote a separate piece on what offline mode in a mobile app actually means, and the build approach for the heavy version is on offline first app development.
On one of our field tools, TimeFix, the work timer had to keep counting while the phone was locked or a call was made from inside the app. That requirement did not exist in the spec and only appeared on real jobs.
Payments are partly a review problem. Apple checks whether money that moves through your app should be going through in app purchases, and for marketplaces and booking apps this is a predictable conversation rather than a surprise.
It is usually resolved by explaining the business model clearly, but it takes calendar time, and the fee model itself is worth understanding before the design is finished. We keep the current numbers on what Apple and Google take.
Three things cost the same in every technology and cause most of the delays we see. The client's Apple developer account being set up late and not configured, which is not a simple process.
Access to third party services arriving after the sprint that needed them. And the absence of one person on the client side who can decide. None of these are Flutter costs, but all three land on the Flutter timeline. The first call brief lists what to bring so they do not.
Buyers who collect three quotes for a shape two product regularly see a spread that has nothing to do with the product. The main causes are where the team sits, how senior it is, and what contract model is being offered.
Location sets the cost base before a line of scope is written. A senior Flutter team in Kraków carries a fraction of the overhead of an agency in Manhattan or Zurich, and that difference is passed straight into the quote.
The work is the same work. What changes is the rent, the salaries and the margin the agency needs to cover them.
This is the reason nearshore teams in Poland have become the default choice for US and Western European companies who want a senior team without a US price, and it is the whole premise of our app development for European companies and NYC businesses pages.
Seniority cuts the other way. A very cheap quote often means a junior team, an offshore body shop, or a low code tool being presented as custom development. The cost shows up later, as a rewrite.
We see this most often when a product built in FlutterFlow hits a real requirement and has to be migrated to Flutter, which costs more than building it in Flutter the first time would have.
Contract model decides who carries the risk. An hourly estimate is a forecast, and the number on it moves with every discovered requirement. A fixed price is a commitment, and the discovered requirements are the agency's problem inside the agreed scope.
We work on fixed price contracts for exactly this reason. The only honest way to do that is to define the scope properly up front, which is why a discovery workshop sits at the start of anything above shape one.
We do not price Flutter work by the hour, and we do not price it by the screen. The quote comes out of the shape and the additions described above, and every scope line has a number attached to it, so the client can see what removing a feature saves before the contract is signed.
A Flutter app does not stop costing money at the store listing. Two lines belong in every budget. The first is the store and payment fees, which are a percentage of revenue and not a development cost. The second is maintenance: OS updates, dependency updates, small fixes and the work of keeping a two year old app on a one year old phone.
Under a fixed price scope, fixes to anything that was agreed and delivered are the agency's responsibility, not a retainer.
Ongoing work beyond that is usually a few percent of the build cost per year for a stable product, and we break that down on mobile app maintenance cost. For a first product, the MVP development page explains how to keep the first version small enough that the maintenance line stays small too.
It depends on the shape: a single flow with one user role, two roles with payments, or a system with a backend and a web admin panel. Apps Value publishes a fixed tier for each shape on its pricing page, and separate cost breakdowns for field service and booking apps.
For the screens and app logic, yes, because one codebase ships both platforms. The backend, design, store setup and project management cost the same as in native. Expect a meaningful saving, not a halving of the whole budget.
Eight weeks and up for a single flow, eight to twelve weeks for two roles with payments, and twelve to twenty two weeks for a full system. Offline work and integrations with an existing system add the most time.
Because the cost base is lower: salaries, office costs and the margin needed to cover them. The team, the process and the deliverable can be identical. The quote reflects where the team sits, not how much work is done.
No. We quote a fixed price against a written scope, with a number on every scope line, and close delivery with a signed acceptance protocol. Larger contracts carry a one year warranty on the software.
Under a fixed price contract, only a change of scope. Requirements that surface in real use inside the agreed scope are our responsibility. Delays, rather than cost increases, usually come from late store accounts and late access to third party services.
Thomas runs Apps Value, a Flutter and React Native agency in Kraków that has delivered 19+ products for clients in the US and Europe on fixed price contracts. He writes about scoping, pricing and the parts of app development that only show up on real jobs.
Bring the shape and the additions from this article to a 30 minute call. You leave with a scope outline and a fixed price range you can take to the rest of your team.
Book an intro call30 minutes, no preparation needed.