23 Flutter Portfolios, 4 Offers, 1 Costly Mistake, the 7-Step Singapore Hiring Method I Use Now

Flutter hiring has a specific failure mode that other stacks do not share. The framework makes it genuinely easy to produce a polished demo, so portfolios converge on a narrow band of visual quality that tells you almost nothing about whether the person can maintain a shipped app. I learned this expensively on the second of three Singapore mandates this year. Here is the method that came out of it.

Step 1: Decide whether you need Flutter or a mobile engineer

The economics of cross-platform are real but conditional. For most product teams below roughly 200,000 monthly active users, one strong Flutter developer ships more than one iOS plus one Android developer at equivalent total cost, because coordinating two native codebases costs more than the cross-platform layer's friction.

That reverses when your product leans on platform-specific capability: advanced camera pipelines, precise background location, complex widget or watch integrations, or anything requiring day-one support for a new OS feature. In those cases native expertise is the constraint, and hiring a Flutter generalist means discovering the limitation six months in.

Write the answer down before you post. It determines whether your assessment should test platform channels or state management, and those are very different filters.

Step 2: Verify every portfolio claim against the public stores

This takes fifteen minutes per candidate and eliminated nine of twenty-three. Open the App Store and Google Play listing for each claimed app. Three checks: does it still exist, when was it last updated, and how many ratings does it have.

Then ask one specific question about something visible in the screenshots. Not « tell me about this app » but « that transaction list on screenshot three, how does it paginate, and what happens if the connection drops halfway? »

The tell is immediate. Someone who owned the work answers concretely and often volunteers what they would do differently now. Someone who contributed peripherally describes the app in marketing language. In mobile hiring specifically, that language shift is the most reliable signal I know.

Step 3: Screen in 20 minutes on release, state and platform channels

« Walk me through your last store release, from merge to users. » You are listening for signing, build flavours, staged rollout, and what they do when crash rates spike after 20% rollout. Candidates who have only handed builds to someone else cannot narrate this.

« How do you decide where a piece of state lives? » There is no correct framework answer. There is a correct kind of answer: one that distinguishes ephemeral UI state from shared application state from persisted state, and explains the cost of getting it wrong.

« Tell me about a time you had to drop to a platform channel. » This reveals the ceiling of their experience. A candidate who has never needed one has probably worked only on straightforward CRUD apps, fine for some roles, disqualifying for others.

Step 4: Run a paid offline-sync assessment

This is the step that would have prevented my expensive mistake. The brief: build a small feature that creates and edits records offline, syncs when connectivity returns, and resolves the case where the same record was edited on the server. Three hours, paid, at home, any tools permitted.

It looks modest and it is brutally discriminating. It forces decisions about local persistence, queueing of pending mutations, conflict policy, and what the user sees while the state is uncertain. A developer who has only built connected screens produces something that loses data on a cold restart, and does so within the first thirty minutes.

Ask for a two-paragraph note with the submission explaining what they chose not to handle and why. That note is frequently more informative than the code, because it shows whether they can identify their own gaps, the trait that most reliably predicts how someone behaves when a production incident starts.

Step 5: Score independently before anyone talks

Two reviewers, five weighted criteria, completed separately: state and persistence design (25%), failure handling and recovery (25%), release and store operations knowledge (20%), code readability and testability (20%), quality of the self-assessment note (10%).

Note what is absent: visual polish. It is not a criterion, deliberately. Flutter makes competent UI cheap, so scoring it rewards the thing that is easiest to fake and hardest to lose sleep over. If design quality matters to your product, that is a design hire, not a mobile engineering criterion.

Step 6: Settle compensation and work pass before you offer

For non-citizen and non-PR candidates working in Singapore, the Employment Pass is the standard route, with a qualifying salary that rises with age and sector and assessment under the points-based Complementarity Assessment Framework. Processing generally runs three to eight weeks, and that timeline needs to be in your offer conversation rather than discovered afterwards.

If the developer will work from outside Singapore, an employer-of-record arrangement in their home country removes the pass question and is typically active within two weeks.

The wider local context is worth stating: Singapore ended May 2026 with 39 unicorns and S$3.21 billion raised across 78 equity rounds, up 13.85% year on year. Funded startups are competing for the same mobile engineers, and they move fast. Our guide to notice period buyouts covers the tactic they use most often to win.

Step 7: Make the first 30 days end in a real store release

The onboarding target is specific: the new developer ships something to production through the full release pipeline within the first two weeks. A copy change is enough. The point is to traverse signing, build configuration, review submission and staged rollout while someone experienced is watching.

Teams that skip this discover the new hire's first release is also their first encounter with a store rejection, four weeks later, under deadline pressure. Two scheduled overlapping hours a week with a named buddy handles the rest, and a day-30 review focused on the role (what surprised you, what still blocks you, what did the job description describe badly) will improve your next posting.

FAQ