A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Flutter genuinely delivers one codebase and two apps, right up to the point where your app needs to do something the framework does not cover.
Then you are writing a platform channel: Dart on one side, Swift and Kotlin on the other, and a serialisation boundary between them that nothing type-checks unless you have adopted Pigeon. Bluetooth, background location, a payment SDK that only ships native, deep linking that behaves differently on each platform, push notification handling when the app is terminated — all of it lands here.
The developer who cannot cross that boundary is not a cheaper Flutter developer. They are a Flutter developer with a ceiling, and you find where it is halfway through a sprint that assumed the plugin ecosystem had you covered.
Dart compounds it. Almost nobody writes Dart for anything other than Flutter, so the pool is not a subset of a large language community. It is its own, smaller thing.
Flutter screening comes down to what happens at the edges of the framework.
Whether they have written one, in Swift and Kotlin, or only consumed plugins somebody else wrote. The ceiling question for Flutter developers.
Provider, Riverpod, BLoC or GetX — we match to what you already run, and we ask why they would choose differently.
Where setState sits in the tree, use of const constructors, and whether they can read a rebuild profile rather than guessing at jank.
Null safety, async and streams, and isolates for genuinely heavy work. Dart is not a language people pick up incidentally.
Signing, staged rollout, and having shipped through both App Store review and Play Console rather than handing builds to someone else.
A live conversation in English, every time. We want to hear somebody say a requirement needs native work before the sprint starts, not during it.
The expensive Flutter outcome is discovering the native boundary after the estimate has been given.
A team scopes a feature assuming pub.dev has a package for it. There is one. It has forty stars, its last commit predates the current major version of Flutter, and it does not compile against your Gradle setup. Now somebody has to fork it, or write the channel from scratch, and that somebody needs working Swift and Kotlin. If nobody on the team has that, the feature stalls while you hire for it — and you are hiring under deadline pressure, which is the worst time.
The second cost is state management chosen by whoever started the project. Flutter never blessed one approach, so the ecosystem carries Provider, Riverpod, BLoC and GetX, each with real adoption. Any of them works. What does not work is two of them in one codebase because the second developer preferred a different one, which is a common outcome on projects that changed hands. You end up with two ways to answer "where does this value come from", and every new person learns both.
Performance failures are quieter. Flutter targets a 16-millisecond frame budget at 60fps, and half of that on a 120Hz display. A widget rebuilding its whole subtree because setState was called too far up the tree will hold frame rate on a flagship test device and drop frames visibly on the mid-range Android handset most of your users actually own. Nothing errors. The app just feels cheap, and the bug reports say "laggy".
Mid-level (3–5 years). Builds screens and flows against an established architecture. Comfortable with the widget tree, navigation, HTTP and whichever state solution is already in place. Consumes plugins rather than writing them.
Senior (5–8 years). Sets the state management approach and defends it, writes platform channels when the ecosystem falls short, and owns build configuration and release for both stores. Can read a rebuild profile and act on it.
Lead (8+ years). Owns mobile architecture across the app, makes the Flutter-versus-native call honestly, handles CI, signing and staged rollout, and decides which native capabilities are worth wrapping properly for the rest of the team.
New app on one codebase. The classic Flutter engagement, and the one where the economics are clearest.
Feature work on an existing Flutter app. The largest category by seat count. Match to the state management already in use rather than hoping somebody adapts.
Platform channel and plugin work. Native capability the framework does not reach. A specialist request, and worth naming explicitly in the brief.
Performance rescue. Jank and rebuild problems on mid-range devices. Usually a bounded engagement of one to two months.
Flutter alongside existing native apps. Common when a team is consolidating. See iOS and Android developers, or React Native if the comparison is still open.
Week one. They run the app on a real mid-range Android device, not just the simulator, and tell you how it feels. Expect questions about which state approach is in use and whether it is used consistently, and expect an inventory of which plugins are actively maintained and which are one abandonment away from being your problem.
Weeks two to four. A shipped feature, plus a considered opinion about the widget tree in one area where rebuilds are wider than they need to be. If any native work exists, expect them to have read the Swift and Kotlin sides rather than treating the channel as a black box.
The warning sign is a developer who only ever tests on iOS. Flutter's rendering is consistent across platforms, which makes it easy to assume behaviour is too. Permissions, background execution, keyboard handling and back-navigation all differ. Somebody who has not opened the Android build by week three is going to hand you a surprise later.
Assuming the plugin ecosystem covers you. It covers the common cases well. The gap is narrow and deep: one unusual hardware requirement, one enterprise SDK that ships native only, and you need somebody who can write the bridge. Audit your requirements against pub.dev before committing to Flutter, not after.
Hiring Flutter without any native experience on the team. This works until it very suddenly does not. You do not need a full iOS and Android team, but you need one person who can open Xcode without flinching and read a Gradle error. Otherwise every build-level problem becomes an outside dependency.
Ignoring which state management the codebase already uses. A BLoC developer dropped into a Riverpod codebase is productive in a fortnight and unhappy for the first week. A developer who quietly introduces their preferred approach alongside the existing one is a problem you will be unpicking for years. Name it in the brief and screen for it.
Testing on flagship hardware only. The whole point of Flutter is reaching a wide device range cheaply. If the test devices are a recent iPhone and a recent Pixel, you have no signal about the experience most of your users get. Buy a mid-range Android handset and make it the acceptance device.
Rates depend on seniority, native depth, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.