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, the €300 product audit is the hour in the repo that settles it.
One codebase, and the engineering that stops doubling
Design, backend, and store review were never twice the work. The client was. Native versus Flutter versus React Native puts two native clients at roughly 1.6–1.9× a single codebase for that reason. A React Native or Xamarin MVP has the same shape once the framework itself is the thing you are maintaining: every screen still has to be understood, rebuilt, and checked.
After the port, a change is one specification, one pull request, one test pass, and one release. The same bug is fixed once and shows up on both phones. A team that can staff two native apps well should keep them. This price is for the team that is already too small for one of them.
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
On a dual-native MVP, the product's speed is whichever platform lagged. Flutter ships one renderer to both stores. Impeller draws the interface, so the slow platform moves up to the same frame budget as the other. Lists, transitions, and the screen that hitches on the second platform become one implementation, fixed once. A tired React Native or Xamarin UI gets the same treatment: one rendered interface, the same on both phones.
A finely tuned app that only ships on one platform still leads on memory, install size, and OS features that shipped this month. Those apps are a different job. The gain here is the gap between your two clients closing, and every later performance fix landing on both phones the same day.
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.