Choose a mobile app development company by checking four things: apps they have shipped and still support, the named people who will build yours, how they handle the work behind the app, and what happens commercially when scope changes. Ask to meet the developers rather than only the account lead before you sign anything.
App projects rarely fail on code. They fail because the back office was out of scope, the estimate assumed clean data, or the team that pitched was not the team that built. This guide covers how to test for each of those before a contract exists.
Key takeaways
- Judge shipped apps, not portfolios: Download what they have built and check the update history in the store.
- Meet the actual team: The people in the pitch are frequently not the people assigned, and nobody will volunteer this.
- Confirm the admin panel is in scope: It is commonly a quarter to a third of the real build and the most frequent source of overrun.
- Settle ownership before signing: Code, store accounts, and what a handover contains if the relationship ends.
Look at apps they still support
A portfolio shows launches. What you need to know is what happened afterwards.
Download two or three of their published apps and check the store listing: when was the last update, do reviews mention crashes or unaddressed bugs, and has it kept pace with recent OS releases? An app last updated two years ago tells you either the client left or the relationship ended badly, and both are worth asking about directly.
Ask specifically for a project that went wrong and what changed in their process afterwards. Every agency with real delivery history has one. A candidate who cannot produce an example either has very little history or is managing you rather than informing you.
Assess four capabilities separately
Product thinking is whether they will challenge your feature list. A team that builds exactly what you specify without testing it against users will faithfully deliver your assumptions, including the wrong ones.
Mobile delivery is store submission, release management, crash monitoring, device fragmentation and the operational habits that keep an app healthy after launch. Ask how they handle a critical bug found on a Friday.
Backend depth matters more than most buyers expect. Almost every business app is a backend with a mobile interface attached, and agencies that are strong on interface and weak on data model produce apps that work in the demo and struggle at volume.
Ownership is the commercial and operational relationship: who holds the accounts, who responds after launch, and what leaving looks like.
Make sure the admin panel is in the quote
Every customer-facing feature creates staff work behind it. Somebody has to manage users, resolve support cases, correct records, and change content without a developer.
That interface is typically a quarter to a third of the total build, and it is the single most common thing missing from a cheap quote. If the proposal does not name it, the work has not disappeared — it will return as a change request, or it will move into direct database access, which is slow, unauditable and expensive to sustain.
Ask each candidate to price the admin interface as its own line. The answers will tell you quickly which proposals were scoped and which were estimated from a feature list.
For what that interface actually needs to contain, see why mobile apps need admin platforms.
Ask who is actually building it
Agencies pitch with senior people and staff with whoever is available. This is normal and not in itself a problem — but you should know before signing, not in week three.
Ask directly: who are the named individuals on this project, what is their experience, are they employed or subcontracted, and what happens if one leaves mid-project. Ask whether the people in this meeting will be among them.
Where work is subcontracted or offshored, that can be entirely fine — but it changes communication overhead, time zones and accountability, and you should be told rather than discover it from a commit history.
Settle the commercial terms that bite later
Get written answers to all of these before signing:
- Who owns the source code, and is it in a repository you control from day one?
- Who owns the Apple and Google developer accounts? These should be yours.
- How are change requests priced and approved, and at what rate?
- What does post-launch support cost, and what response time does it commit to?
- What is handed over if the relationship ends, and in what state?
The developer account question is worth insisting on. Apps published under an agency's account are painful to move, and the moment you discover this is usually the moment the relationship is already difficult.
Test with a small paid engagement
The most reliable signal is how a candidate behaves on real work. Where you can, start with a paid discovery or a small first phase — two to four weeks, scoped so the output is yours to take elsewhere.
Watch whether they ask about your existing systems, your exceptions and the people who will operate the result, or whether they move straight to screens. A team that asks about failure states before it asks about visual design is a team that has shipped something and supported it afterwards.
The cost of that engagement is small against the cost of discovering the mismatch six months into a fixed-price build.
Related guides
Related reading:
- How to Define a Mobile App MVP That Tests the Business
- How to Build a Business Case for Custom Software
- How to Choose a Digital Transformation Partner
If the work prompted by How to Choose a Mobile App Development Company leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Mobile Product.
Ali Boran Gazel