Short answer: on a complex mobile build, prioritise the partner's first-fortnight architecture judgement over everything else — offline model, sync conflict resolution, background behaviour, schema versioning and release risk. Those decisions are made before anything looks like an app, and they are the ones you cannot cheaply undo.
Why mobile punishes mistakes differently
A wrong decision on the web is redeployed on Tuesday afternoon. A wrong decision on mobile is installed on devices you do not control, running a version you cannot recall, used by people who will not update.
Fixing it means an over-the-air migration that tolerates every version ever shipped, cannot be rolled back, and passes store review. That asymmetry should shape the entire vetting process: you are hiring judgement exercised in week one, not the ability to build screens in month four.
The five priorities, and how to test each
### 1. Offline and sync model
Why it matters: it determines the data schema, the API shape and the interface, and changing it later is a rewrite.
How to test: "Two devices edit the same record while both are offline on a train. What happens?" A serious team names an approach — server-authoritative merge, last-write-wins with vector clocks, CRDTs for specific fields — and explains what the user sees when it conflicts. Vagueness means they have never shipped it under real conditions.
### 2. Background behaviour
Why it matters: sustained background location, uploads and sync are where the two platforms differ most, and where battery complaints and one-star reviews originate.
How to test: ask for a shipped app that tracks location across a working day, and ask what they had to do to survive OS power management. The answer is full of specifics if they lived it and generic if they did not. We learned ours building driver and dispatch apps for national taxi operators, and the specifics are not guessable.
### 3. Schema and API versioning
Why it matters: old clients live for months. Every API change must serve versions you cannot upgrade.
How to test: "How do you version the API, and what is your policy for clients three versions behind?" Look for backwards-compatible evolution, a forced-upgrade mechanism, and a defined support window rather than an aspiration.
### 4. Release risk management
Why it matters: no rollback exists on mobile.
How to test: ask for their release process. You want staged rollout with monitored crash rates, remote feature flags and a kill switch, forced-upgrade capability from day one, and a rehearsed procedure for a bad release. "We test thoroughly" is not a release process.
The question is not whether they ship bugs. It is what they can do on the afternoon a bug ships.
### 5. Hardware integration, if relevant
Why it matters: Bluetooth peripherals, printers, scanners and payment terminals are where cross-platform abstractions leak, and where schedules quietly double.
How to test: ask for a shipped product using the same class of hardware. Treat "we can learn it" as a risk you are funding, and price it as discovery rather than build.
What matters less than people think
Framework preference. A senior team ships well in any of the current options. A strong opinion is fine; a religion is a warning sign.
Portfolio size. Two relevant apps beat forty irrelevant ones.
Agency headcount. Your project is built by four to six people regardless. The rest of the organisation is overhead you are financing.
Design polish in the pitch. Beautiful decks are cheap. Ask to see a shipped app's empty states, error states and offline state — those are where care actually shows.
The evidence pack to demand
Before signing anything, ask for:
1. Two shipped apps you can install, with the named engineers who built them.
2. A written description of the offline and sync model from a previous project.
3. Their release checklist, names removed.
4. A post-incident note from a real production problem.
5. The contract clause transferring repository, store accounts and signing keys to you at commit one.
Firms that have done complex mobile work produce all five within a couple of days. Firms that have not produce a deck.
Then buy a fortnight
Scope the trial slice at the hardest part — the sync, the background job, the hardware handshake — not the onboarding screens. Fixed price, production, tests, documentation.
Ours is €9,500, the record is open in a browser, and the contact form reaches an engineer rather than an account manager.
Frequently asked
What matters most on a complex mobile build?
The architecture decisions made in the first two weeks — offline model, sync conflict resolution, background behaviour, data schema and versioning. They are cheap to get right then and close to unfixable later, because your code is on devices you no longer control.
How do I test a partner's offline and sync competence?
Ask how two devices editing the same record on a train get reconciled. A serious team names a strategy — last-write-wins with vector clocks, CRDTs, server-authoritative merge — and explains the trade-off. A vague answer means they have not shipped it.
What is release risk on mobile?
A bad release cannot be rolled back; it can only be superseded by a review-gated update, while old versions keep running for months. Staged rollout, remote kill switches, forced-upgrade handling and backwards-compatible APIs are the mitigations to demand.
Does hardware integration change the choice?
Yes. Bluetooth peripherals, printers, payment terminals and scanners are where cross-platform layers leak. Ask for a shipped product with the same class of hardware, and treat 'we can learn it' as a schedule risk you are funding.