Flutter's hiring pool is small, and that is the whole problem.
Dart is not a language anyone learns by accident, so the population is smaller than for React Native and considerably smaller than for native. Screening matters more when there are fewer candidates, not less.
- 01LanguageDart, a deliberate choice
- 02ShippedBoth stores, not just a build
- 03StateRiverpod, Bloc, or a defended choice
- 04EngagementMonthly rolling, 30 days notice
- 05InterviewYou meet them, you can decline
- 06Overlap4–6 hours with US and EU
Nobody arrives at Dart casually.
That cuts both ways. The population is small, so a search takes longer and the market is tighter than the demand would suggest. But everyone in it chose to be there, which filters out a category of accidental candidate you get in larger ecosystems.
What it does not filter is store experience. A great many Flutter developers have built applications and rather fewer have shipped one to both stores, handled a rejection, managed signing and provisioning across a team, and dealt with a release that had to be pulled.
That is the gap we screen hardest for, because it is the part that hurts most when it is missing and the part least visible on a CV.
The second gap is native. Flutter covers a great deal, and every non-trivial application eventually needs something it does not: a specific SDK, a background behaviour, a piece of hardware. An engineer who cannot write or read a platform channel will hit a wall and the project will stop there.
Flutter, React Native or native.
We staff all three, so this table is not an argument for our bench. The decision is usually made on team and design, not on technology.
| Choose | When | The cost |
|---|---|---|
| Flutter | One design across both platforms, rich custom UI, small team | Small hiring pool; Dart is used nowhere else in your stack |
| React Native | You already have React engineers and a web front end | Native knowledge still required; the shared-skills case is overstated |
| Native (Swift + Kotlin) | Platform-specific feel, deep hardware use, or the app is the business | Two codebases, two teams, two release cycles |
| A web application | No hardware requirement and no genuine need to be in a store | None, usually, and it is asked far too rarely |
What we ask a Flutter engineer.
Weighted towards shipping rather than building, because that is where the gap usually is.
What is in the stores under your name?
Live links. The single most useful question, and the one that most often ends an interview early.
Which state management, and why that one?
Riverpod, Bloc, Provider; any is fine with a reason. No opinion means no application of size.
Have you written a platform channel?
The boundary where Flutter stops. An engineer who has never crossed it will stall on the first native requirement.
How do you handle a rebuild storm?
Widget rebuild scope, const constructors, and the DevTools timeline. Performance in Flutter is mostly about rebuild discipline.
What was your last store rejection?
Everyone who ships has had one. What it was and how they resolved it tells you whether they own releases or hand them over.
How is it tested on real devices?
Emulators hide the problems that matter. We are listening for a device matrix, or at least an awareness that one is needed.
What “one codebase” actually covers.
Flutter's cross-platform claim is stronger than React Native's and it is still not total. Knowing where the line falls prevents the third-month surprise.
One codebase, both platforms
- UI, Flutter renders its own widgets
- Business logic and state
- Networking, storage, serialisation
- Most animations and transitions
- Testing, for the shared layers
Budget for these
- Signing, provisioning and store configuration
- Push notifications, properly configured
- Deep links and universal links
- Permissions and background behaviour
- Anything reaching a platform SDK, via a channel
- Store review, twice, with different reviewers
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring Flutter engineers.
Three that change the shape of a mobile engagement.
Is Flutter a safe long-term bet?
It is well established, widely used in production and backed by a large organisation, and those are the structural things worth checking. The honest risk is not technical, it is corporate: a framework with a single corporate sponsor carries a strategic risk that an independent one does not, and that is worth weighing on a ten-year system even though the day-to-day experience is excellent. The practical mitigation is the same as for any framework choice, keep business logic separable from the UI layer, so that a future move is a rewrite of the presentation, not of the application. Our engineers structure it that way by default.
Will our web developers be able to work on it?
Less easily than with React Native, and the difference is Dart. React Native at least shares a language and a component model with your web front end, so a React engineer can contribute to screens within days. Flutter shares neither: Dart is a new language, and the widget model is different from anything on the web. A good engineer will learn both in a few weeks, but it is a few weeks instead of a few days, and it is time you should plan for, not discover. If the ability to move engineers between web and mobile is important to you, that is a real argument for React Native even though Flutter is the stronger framework in several other respects.
Do we need a designer as well?
More than with native, and this catches teams out. On native, the platform's own design conventions do a lot of work for free, an app built with standard iOS components looks like an iOS app without anyone deciding anything. Flutter draws its own widgets, which means it will happily render whatever you specify, including something inconsistent. The freedom is exactly why teams choose it for a strong brand identity, and it is also why a Flutter app without design input tends to look less finished than a native one. Budget for a designer, or accept that it will look generic.