How to Judge a Flutter Developer Without Code

You cannot audit the code, so audit the decisions

If you are commissioning an app without an engineering background, the usual advice — "review their GitHub" — is useless. You cannot tell good Dart from bad Dart, and neither can most of the people giving that advice.

What you can assess is how someone explains a decision. Experience shows up as specificity about trade-offs. Inexperience shows up as enthusiasm without cost.

Here is what to ask.

Ask for shipped listings, not repositories

A GitHub profile proves someone writes code. A live App Store and Google Play listing proves they finished something, passed review, and handled the parts that are not programming: privacy declarations, age ratings, screenshots, data-deletion paths.

Ask for store links. Then open them, look at the review dates, and check the app has been updated since launch. Shipping once is a project; shipping updates is a practice.

Four questions and what the answers tell you

1. "Which state management do you use, and why not the others?"

The answer to look for is not a name. It is a reason attached to a context — something like *Bloc for large apps with many collaborators because the boundaries are explicit; Riverpod when the graph is smaller and the ceremony is not worth it.* We use both, split that way.

A warning sign is a single answer defended universally. There is no state management that is correct for every app, and someone who has shipped several will have changed their mind at least once.

2. "What happens in your app when the network drops?"

This is the fastest test for whether someone has shipped to real users. A developer with production experience answers immediately, because it is the first thing that breaks in the field. One who has only built to a demo will treat it as an edge case.

3. "How do you find out something broke in production?"

You want to hear crash reporting and analytics named as things they set up by default, before launch — not as an add-on. Anyone who says "the users tell us" has not run a real app.

4. "Show me a decision you got wrong and had to reverse."

The most useful question on the list. A senior engineer has a ready answer with detail: what was chosen, what it cost, what replaced it. No answer, or a fake-humble one ("I care too much about quality"), means either not enough shipped work to have been wrong, or not enough reflection to notice.

Red flags worth taking seriously

• No CI. If builds are made on someone's laptop, releases depend on that laptop and that person.
• Tests "later". Later never comes. You do not need full coverage, but zero on a project of any size is a decision, not an accident.
• No questions about your business. An engineer who does not ask who uses this and what success looks like will build exactly what you specified, including the parts that were wrong.
• A fixed quote before scoping. A confident number with no discovery is a number that will change; the only question is whether it changes before or after you sign — what a real timeline assumes.

The cheapest test of all

Ask for a working build on your own device in the first week — even one screen, even fake data. Teams that ship early ship. Teams that go quiet for a month and reappear with a demo are managing your perception rather than the risk.

That single request tells you more than any interview, and it costs nothing to make.