Seven Technical Checks Before You Hire a Flutter Team

Alona Fadieieva — Tue, 11 Aug 2026 15:16:51 +0000

Most "how to pick a dev agency" advice is unfalsifiable. Check their portfolio. Look at reviews. Make sure communication is good. None of it distinguishes a team that has shipped hard Flutter work from a team that finished a course.

The checks below are technical and they have wrong answers. They come out of running a Flutter-only shop since 2019 — the longer, buyer-oriented version of this lives on our blog, including a breakdown of European Flutter companies. This post is the engineering half: what to actually ask, and what a weak answer sounds like.

1. How do they cross the platform boundary?

This is where cross-platform projects fail, and it's the fastest way to find the bottom of someone's Flutter knowledge. Anything touching platform APIs — Bluetooth, camera hardware, background execution, biometrics, health data — leaves Dart.

A team that's done this will talk about MethodChannel and EventChannel fluently, and will usually tell you they've moved to Pigeon for anything non-trivial:

// The raw approach — fine for one or two calls
class BatteryService {
  static const _channel = MethodChannel('com.example.app/battery');

  Future<int?> getBatteryLevel() async {
    try {
      return await _channel.invokeMethod<int>('getBatteryLevel');
    } on PlatformException catch (e) {
      log('Battery channel failed: ${e.code}', error: e);
      return null;
    }
  }
}

Two things to listen for. First, does the error path exist? PlatformException is not optional — a channel call fails differently on each platform, and a team that hasn't hit that hasn't shipped. Second, at what point do they stop hand-writing channels?

The answer should be Pigeon. Hand-rolled invokeMethod calls are stringly-typed on both sides of the boundary: rename a method in Kotlin and Dart finds out at runtime, in production. Pigeon generates typed bindings from a Dart schema, so the mismatch becomes a compile error:

// pigeons/battery_api.dart
@HostApi()
abstract class BatteryApi {
  int getBatteryLevel();
  bool isCharging();
}

For continuous native data — sensor streams, BLE characteristic notifications — the equivalent question is EventChannel and how they handle the subscription lifecycle. Streams that don't get cancelled on dispose are a common source of leaks in apps that talk to hardware.

Weak answer: "Flutter handles the native side." It doesn't. It gives you a well-designed way to write the native side yourself.

2. What's their SDK version policy?

Google ships four Flutter and four Dart releases a year. A team several versions behind is accumulating migration debt that transfers to you at handover, and the cost isn't linear — skipping four releases is worse than four times skipping one, because breaking changes compound and the migration guides assume you're stepping through.

Ask to see a pubspec.yaml from a current project:

environment:
  sdk: ^3.12.0
  flutter: ">=3.44.0"

Then ask how they decide when to upgrade. Good answers involve a stated cadence and a regression suite. Bad answers involve "when a client asks" or "when something breaks."

The related question is dependency hygiene. Running this on a real project tells you more in ten seconds than an hour of discussion:

flutter pub outdated

A long tail of abandoned packages pinned to old constraints is how projects become unupgradeable. Ask what their policy is on adding a dependency — teams with judgment have one, usually some version of "if it's under 200 lines, we write it."

3. Impeller, and whether they know why it matters

Impeller replaced Skia as the renderer, became the Android default during 2025, and completed its rollout with Flutter 3.44 in 2026. The reason it exists is shader compilation jank: Skia compiled shaders at runtime, so the first time an animation ran you'd drop frames. Impeller precompiles.

Why this is a useful question: it's a topic where surface knowledge and real knowledge sound different. A team that's debugged jank will talk about specific profiling work — flutter run --profile, the timeline view in DevTools, raster thread vs UI thread. A team that read the release notes will say Impeller made things faster.

Follow-up worth asking: what do they do when the raster thread is the bottleneck versus the UI thread? These have completely different fixes, and conflating them is the single most common performance mistake in Flutter.

4. State management — and whether they're dogmatic about it

There's no correct answer to "Riverpod or Bloc or signals." There is a wrong answer, which is a team that can only work in one and will architect your product around that constraint regardless of fit.

What you want to hear is reasoning about scope: what's ephemeral widget state that belongs in a StatefulWidget, what's shared application state, and where the boundary sits between state management and the data layer. A team that reaches for a global store to hold a text field's contents is telling you something.

The more revealing question is testing. Ask what proportion of their state logic is testable without a widget tree:

test('cart total recalculates on quantity change', () {
  final cart = CartNotifier();
  cart.add(Item(id: '1', priceCents: 1000), quantity: 2);
  expect(cart.state.totalCents, 2000);
});

If business logic can only be tested by pumping widgets, it's in the wrong layer.

5. Release engineering

Flutter's build story has more moving parts than it looks: flavors, signing, per-platform entitlements, and now Swift Package Manager as the iOS default rather than CocoaPods. Ask what happens between "merged to main" and "on a device."

Concrete things to probe:

Flavors. Dev, staging, and production as real build configurations, not a const bool isProd in a Dart file.
CI. Are builds reproducible on a clean machine, or does the release depend on one developer's laptop?
Signing and provisioning. Who holds the keys, and what happens when the person who set it up is on holiday?
Store submission. Ask about the last rejection they got and how they resolved it. Everyone gets rejected; teams that ship a lot have specific stories.

Obfuscation is worth asking about too, both for binary size and because it forces the question of whether symbolicated crash reporting is wired up:

flutter build appbundle --obfuscate --split-debug-info=build/symbols

An obfuscated release without uploaded symbol files means every production crash is unreadable.

6. Where the data goes — as an architecture question

This usually gets filed under legal, but it's an engineering constraint that shapes the app.

Under GDPR Chapter V, transfers of personal data outside the EEA need safeguards, and a US cloud provider's "EU region" doesn't remove US jurisdiction under the CLOUD Act. The part that catches Flutter teams specifically: if your app calls a non-EU model endpoint, each call is processing, even when nothing persists server-side. Storing locally doesn't make the inference call disappear.

The architectural consequences are real. On-device inference means a bundled model, size budgets, and a different update story. EU-hosted infrastructure means picking providers before you write the data layer, not after. Ask a candidate team where user data sits while the app runs and where it's processed — they're different questions, and a team that treats them as one hasn't dealt with it.

Worth noting for anyone planning around the EU AI Act: the high-risk obligations that were due August 2, 2026 were deferred by the Digital Omnibus to December 2, 2027 for Annex III systems and August 2, 2028 for Annex I. Article 50 transparency duties were not deferred and are live now. If your app has a chatbot or generates synthetic media, those disclosure obligations already apply.

7. Where they draw the AI line

Flutter 3.44 shipped Agentic Hot Reload — the Dart/Flutter MCP server can find a running app and trigger a reload when an agent applies a change — and GenUI, built on the open A2UI protocol, which lets an agent compose real widgets from your app's catalogue rather than returning markdown.

Both are genuinely interesting and neither is settled. The genui package was still alpha as of the mid-2026 docs, and a full prompt cycle can emit several thousand tokens per request, which is a real cost at scale.

So the question isn't "do you use AI." It's where the line sits. The answer we give: agents are good at boilerplate, test scaffolding, and mechanical refactors, and bad at deciding what the architecture should be. Anything that's expensive to reverse — data model, module boundaries, auth flow, native integration surface — gets decided by a senior engineer who will still be there in six months.

A team without a stated position on this is either not using the tools or not thinking about them. Both are worth knowing.

The short version

If you only ask two, ask about platform channels and about SDK upgrade policy. The first tells you whether they've shipped something hard. The second tells you what shape the codebase will be in when you inherit it.

What would you add? I'm curious which of these people have actually used in a vendor call.

Written by the team at HotShots Labs, a Flutter-only development studio registered in Estonia and listed in Google's Flutter Consultant Directory. We build iOS, Android, web, and tablet apps from a single Dart codebase — project-based, dedicated team, or staff augmentation. The full guide this is adapted from, including a breakdown of European Flutter companies, is on our blog.

DEV Community: Alona Fadieieva