You already shipped the MVP. Then the second client showed up. Swift in one repo and Kotlin in another, or a React Native app whose upgrade tax is now the product, or a Xamarin app sitting on a stack that is running out of road. The behaviour did not double. The maintenance did, and so did the amount of code an agent has to read before it can change a screen.
This is a fixed port of that MVP to Flutter, for €15,000. It replaces the clients you have now. A Flutter module left inside the old native shells keeps both codebases on the engineering bill and on the token bill, so that shape of migration sits outside this price.
What the €15,000 covers
The app is already live, or already in TestFlight and internal testing. The job is to move the behaviour users already have onto one Flutter codebase that ships to both stores.
- The flows that are in the stores today. Sign-in, the main loop, and the screens those flows need. Native, React Native, or Xamarin: what carries over is the API and the behaviour. The widgets are written once, in Flutter.
- A parity list, signed before week one. That list is the scope. A side-by-side pass against the current app happens before handover.
- Installable builds on iOS and Android, submitted with you.
- Thirty days of fixes on behaviour that was on the list and came across wrong.
- The repository, the builds, and the handover notes. You keep them.
What keeps the price at €15,000
The price matches the app that is already shipping. A larger product is a separate quote, given before any build starts.
- New features, a new visual design, a backend rewrite, or a new billing system.
- A compliance rebuild for health or finance.
- Widgets, Live Activities, CarPlay, Wear, and App Clips.
- An offline sync model that has to be redesigned.
- A Flutter module embedded in the old shells. This price replaces the clients.
Send the store links and the list of flows. If that list is the MVP, the price is €15,000. If the list is a whole product, you get a different number while everyone is still in a call. When the list is not enough to tell, an optional focused one-hour senior diagnosis for €300 can answer an agreed question. You do not need it when the scope is already clear; a full audit has a separate scope.
One codebase, and the engineering that stops doubling
Product decisions, design and backend work can be shared, while separate platform clients need their own implementation and checks. The native, Flutter and React Native comparison explains how to compare the same scope without a universal price multiplier. A migration still requires understanding, rebuilding and checking the agreed screens.
A shared codebase can reduce repeated implementation and let one correction benefit both clients. It does not remove iOS and Android device tests, native integration work or separate store releases. Teams that can maintain their existing clients well may have no reason to migrate.
The AI token bill
Agent tools charge for the code they read. A change to a screen that exists in Swift and in Kotlin loads both trees, proposes two diffs, and reviews two test suites before anyone argues about the feature. A React Native or Xamarin tree has the same cost once the agent has to hold the framework, the native modules, and the screen at the same time.
The backend, the design, and the store listing stay a single piece of work. The client work is what repeats, and after launch it is most of the token spend. One Flutter tree means one read, one diff, and one review on every change after the migration. The same saving shows up when a person does the work without an agent. The agent just makes the duplicate invoice visible.
Performance
Flutter can share rendering and application code, but the same code does not guarantee the same frame rate on different devices. We profile the agreed critical flows on target iOS and Android hardware, including scrolling, transitions, startup and memory, then investigate measured regressions.
Native integration depth, device capabilities, accessibility, install size and operating-system behavior remain part of the decision. A migration is worthwhile when it meets the agreed functional and performance criteria; changing frameworks alone is not a performance guarantee.
Four weeks
The calendar matches two build sprints because the product already exists. The work is the port. I do it.
- Parity map. The live flows, written down, with what is in the €15,000 and what is not. You sign it.
- Port. Those flows in Flutter. A build you can install each week.
- Both stores, side by side. The new app against the old one, on the flows in the list.
- Gaps, then handover. Fixes for anything in the list that does not match. Repository, notes, and the 30-day window on those flows.
Where a greenfield quote still applies
A product that does not exist yet is the range in what an MVP costs in 2026: a single validated flow, or a full consumer MVP with payments and push, depending on what has to be invented. This €15,000 is the other situation. The invention already happened. What is left is one codebase that can carry it.