Flutter makes it possible to ship iOS and Android apps from one codebase — but only if the developer knows how to structure a real app, not just a demo. Use this Flutter developer hiring checklist to assess candidates or agency engineers before they touch your product.
The 12-point checklist
1. Dart fundamentals
Null safety, async/await and Futures, Streams, immutability and records. Ask them to explain what happens when an exception is thrown inside an async function that nobody awaits.
2. Widget composition
Can they break a screen into small, reusable widgets, and explain when to use StatelessWidget versus StatefulWidget, and why const constructors matter for rebuilds?
3. State management
They should know at least one approach deeply — Riverpod, Bloc or Provider — and explain why they chose it. See our comparison of Flutter state management options.
4. Project structure
Feature-based folders, separation between UI, state and data layers, and a repository or service layer that isolates API calls.
5. API integration
REST calls with proper models, error handling, retries, timeouts, token refresh and loading/empty/error states on every screen.
6. Firebase and backend services
Authentication, Firestore, Cloud Messaging and Crashlytics — and an understanding of Firestore security rules, not just client code.
7. Offline and local storage
Caching and local persistence (for example SQLite-based packages or key-value stores), and what happens when the device reconnects.
8. Navigation and deep links
Declarative routing, handling deep links from notifications and emails, and preserving state across navigation.
9. Testing
Unit tests for logic, widget tests for screens and a few integration tests for critical flows. A developer with no testing habit will cost you in regressions.
10. Performance
Using Flutter DevTools to find expensive rebuilds, jank and memory issues; lazy lists; image caching and sizing.
11. Native features
Permissions, push notification setup on iOS and Android, payments and in-app purchases, and writing a platform channel when a plugin does not exist.
12. Release and maintenance
Build flavors for dev/staging/production, code signing, App Store Connect and Google Play Console, CI builds, and upgrading Flutter and packages without breaking the app.
A practical interview format
- App walk-through (30 min): they show an app they built and explain structure, state management and one hard problem.
- Live exercise (45 min): build a screen that lists items from a public API with pull-to-refresh, loading, empty and error states.
- Architecture discussion (30 min): "How would you add offline support and push notifications to this app?"
Interview questions that reveal experience
- What causes unnecessary widget rebuilds and how do you find them?
- How do you store and refresh authentication tokens securely?
- How have you handled an App Store rejection?
- What breaks most often when upgrading Flutter, and how do you manage it?
- How do you structure environment configuration for different builds?
Red flags
- All logic inside widgets and
setStateeverywhere in a large app. - No experience publishing to the stores.
- API keys or secrets hard-coded in the app.
- No tests and no opinion on testing.
- Cannot explain the state management approach they claim to use.
Contract, dedicated or project?
For a release deadline or a specific feature, a contract Flutter developer is often the fastest route. For continuous product development, a dedicated developer builds deeper knowledge of your app. Read contract vs dedicated developers to decide.
Key takeaways: test Dart, structure, state management, API handling, testing and release experience with realistic exercises. Watch for business logic in widgets, hard-coded secrets and no store experience.
Need a vetted engineer? See our Flutter developers for hire or request a developer.
