Hiring a Flutter Developer: What to Look For (From Someone Who Gets Hired)

A surprising amount of my work starts with a rescue. The previous developer disappeared, the app crashes on half the devices, and nobody has the signing key. The founder did nothing wrong except hire someone without knowing what to check.

I’ve been on the other side of the hiring table for years: freelancing on Upwork since 2021, working with teams like Shiftboard and Mascopia, and running my own studio. I’ve seen what good clients look for, and what they wish they’d checked earlier.

This is that checklist. It’s written for founders and product owners who don’t write Flutter themselves but need to hire someone who does.

Start with shipped apps, not portfolios

Screenshots and Dribbble shots are easy. Apps that are live in the App Store and Google Play are not. Getting an app through review, handling signing, crashes and updates is a different skill from building a nice-looking demo.

Ask for store links, not screenshots. Then:

• Install the apps. Do they open quickly? Do they feel smooth? Do they handle a bad connection?
• Check the dates. When was the last update? Apps that are still maintained say more than apps abandoned after launch.
• Read the reviews. Look for patterns in complaints, keeping in mind the developer may not have controlled everything.
• Ask what they did. “I built the whole app” and “I fixed bugs in the checkout” are both valid, but they’re different. A good developer is specific about their role without being asked twice.

Ask architecture questions, even if you can’t judge the code

You don’t need to read Dart to learn a lot from how someone talks about their work. Ask open questions and listen for clear, specific answers:

• “How do you structure a Flutter project?” You want to hear about separating UI from business logic and data, not “I put everything in the screen.” (I describe my own approach in pragmatic clean architecture in Flutter.)
• “Which state management do you use, and why?” Riverpod, Bloc and others are all fine. The why matters more than the choice. “It’s what I always use” is weaker than “it fits apps with lots of async data, and here’s the trade-off.”
• “How do you test?” Listen for a mix of unit tests for logic, widget tests for key screens, and some end-to-end checks for critical flows like sign-up and payment.
• “How do builds get to the stores?” Someone who has set up CI/CD will describe automated builds, signing and staged rollouts. Someone who hasn’t will describe building on their laptop.
• “What happens when a payment fails?” This is my favorite. A strong answer covers the card being declined, the network dropping mid-payment, the user closing the app, and webhooks arriving late. A weak answer is “it shows an error.”

If you have a technical friend or advisor, ask them to sit in on this conversation or look at a code sample. Thirty minutes of their time can save you months.

Communication is half the job

Most failed projects I’ve inherited didn’t fail because the developer couldn’t code. They failed because the client didn’t know what was happening until it was too late.

Signs of good communication:

• They ask questions about your users and business before talking about technology.
• They push back when something is risky or unnecessary, and explain why in plain language.
• They give estimates as ranges with assumptions written down, not a single suspiciously round number. (I explain why in how I estimate a mobile app project.)
• They propose regular demos of working builds, not just status messages.
• They tell you about problems early, even awkward ones.

One client summed up what that looks like from the founder’s side:

“Hired for a specific purpose to update my mobile app. He did the job well, quickly, and was great with communication. Would hire again.” — Ben Silverstein

“Great with communication” is what clients mention first, more often than anything technical.

Red flags

Some warning signs I’d take seriously:

• No store links, or only links to apps that haven’t been updated in years.
• A fixed price within minutes of hearing a one-paragraph idea. Either they didn’t think about it, or the price will change later.
• “Everything is easy.” Payments, subscriptions, live location and offline sync are not easy. Someone who has built them knows where the pain is.
• Reluctance to use your accounts. They want to publish under their developer account or keep the repository private “until the end.”
• No mention of testing, crash reporting or updates. That usually means none of those will happen.
• Long silences. If they’re slow to respond while trying to win your project, it won’t improve after.

How to run a trial task

A small paid trial is the best way to see how someone actually works. A few tips:

• Pay for it. Good developers are busy, and unpaid tests attract people with nothing else to do.
• Make it real but small. A single screen with an API call, loading and error states is plenty. Avoid trick puzzles.
• Judge the process, not just the result. Did they ask clarifying questions? Did they handle the error case without being told? Did they explain what they’d do differently with more time?
• Ask for the code in a repository you own. Then ask your technical friend to look at it.

You must own the code, accounts and keys

This is the part founders most often get wrong, and it’s the most expensive to fix later. Before any work starts, agree that you own:

• The source code, in a Git repository under your account or organization, with the developer invited as a collaborator.
• The Apple Developer and Google Play Console accounts. Apps should be published under your name, with the developer given access as a team member.
• Signing keys and certificates. The Android upload key in particular: without it, updating your app becomes slow and painful. Keep a copy somewhere safe that isn’t the developer’s laptop.
• Backend and third-party accounts: Firebase, cloud hosting, Stripe, RevenueCat, maps, email providers. Billing in your name, developer added as a user.
• Domains and API keys.

Any experienced developer will be fine with this. It protects you if they get sick, get busy or simply move on, and it makes the handover painless if you ever bring someone else in. I’ve picked up enough apps where none of this was in place to know how much it matters. (Here’s how I take over an existing Flutter app when it does happen.)

Takeaways

• Ask for store links to live, recently updated apps, and ask exactly what the developer built.
• Use open questions about architecture, testing, releases and failed payments; listen for specifics.
• Prioritize communication: questions, honest pushback, ranged estimates and regular demos.
• Watch for red flags like instant fixed prices, “everything is easy” and reluctance to use your accounts.
• Run a small, paid, realistic trial task and judge the process as well as the result.
• Own your code, store accounts, signing keys and service accounts from day one.

If you’re looking for a Flutter developer and want to see how I’d approach your project, get in touch.