Every mobile agency shows polished screenshots and a list of frameworks. None of that predicts what happens when a release breaks in the store, when an OS update lands mid-project, or when you want to take the code in-house. These questions do.
01Questions about after launch
Most of a mobile app's life is post-launch, and most proposals price only the build. The answers here separate a delivery vendor from a partner.
Ask who holds the store accounts. If the agency owns the Apple and Google developer accounts, your app lives in their tenancy - transferring later is possible but disruptive, and in a dispute it is leverage against you. The accounts should be yours from day one, with the agency added as a user.
Ask what happens on the next OS release. A partner who has run apps for several years will describe a routine; one who has not will treat it as a change request.
Ask how they handle a bad release. The answer should mention staged rollouts, kill switches and server-side flags. If it is 'we test thoroughly', they have not operated an app at scale.
- Who owns the store accounts, signing certificates and push credentials?
- What is the process when a release causes a spike in crashes on Friday evening?
- How do you handle annual OS updates and minimum SDK changes - is that quoted separately?
- What can be changed without a store release, and what cannot?
- What does handover look like if we take it in-house in a year?
02Questions that reveal engineering depth
These are specific enough that a rehearsed answer is obvious.
Ask how they decide between cross-platform and native for a given product. A partner with a single answer regardless of the product is selling their existing skillset rather than assessing yours.
Ask what they do about offline behaviour and flaky networks. Teams who have only built connected apps in offices tend not to have an answer, and it is the most common source of field failures.
Ask to see a crash dashboard from a live app they run, with real numbers. Willingness to show operational reality rather than screenshots is the strongest single signal.
03Commercial terms that matter for mobile
Mobile has specific contractual issues that general software agreements miss.
Source code and asset ownership should transfer on payment, including build configuration and signing material - a codebase you cannot build and sign is not a codebase you own.
Fixed-price mobile projects should carve out platform-mandated work. An OS release that forces an SDK upgrade mid-project is not scope creep, and a contract that treats it as such creates a fight at the worst time.
Support terms should specify response times for store-blocking issues separately. An app that cannot be submitted is a different severity from a cosmetic bug.
04What good looks like
A partner worth having will ask about your users' devices and networks before proposing a framework, will tell you which parts of your idea are expensive, and will describe maintenance as a standing cost rather than a footnote.
They will also be comfortable with you owning everything from the start. Any reluctance there is the clearest early warning you will get.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer