How do you choose a mobile app development company?
Judge a mobile app development company on the things that outlive the pitch: who owns the store accounts and the code, how a release gets out of the door, and what the quote covers once the app is live. A portfolio tells you what shipped. It tells you nothing about what it cost to keep shipping.
Four questions separate a comfortable app project from an expensive one, and none of them are answered by a demo.
- Who owns the developer accounts? The Apple and Google accounts should be in your company's name from the first day, with the agency invited into them.
- How does a release actually get out? Ask who can ship an update, how long it takes, and what happens when that person is on holiday.
- What is the quote assuming? A number with no assumptions attached is a number that is going to move.
- Who is looking after this in month four? Both mobile operating systems change every year whether or not anyone is maintaining your app.
This article used to be a list of things to look for in a developer. Most of that list still holds, but it described a market where building a good-looking app screen was hard. It is not hard any more, and that changes which parts of a pitch are worth trusting.
The portfolio is the least useful part of the pitch
A portfolio is curated by definition. It shows the projects a company is proud of, at the moment they looked best, and often built by people who have since moved on.
It is also the part of a pitch that AI tooling has made cheapest to produce. A polished screen, a smooth prototype and a convincing walkthrough now take a fraction of the effort they took three years ago, which means they prove a fraction of what they used to.
There is one genuinely useful thing you can pull out of a portfolio, and it takes two minutes. Look each app up in the App Store or on Google Play. Both listings publish the date of the last update, so you can see for yourself whether the apps a company shows you are still alive or were handed over and abandoned.
What to ask instead, and what each answer tells you
The usual shortlist questions are not wrong, they are just answered too easily. Each one below has a version that is harder to answer smoothly, which is exactly what makes it useful.
| What buyers usually ask | What the answer really tells you | Ask this instead |
|---|---|---|
| Can we see your portfolio? | Which projects they are proud of, and nothing at all about how those projects went. | Which of these are still live, and when was each one last updated? |
| How much will it cost? | A number resting on a scope nobody has agreed yet. | What is this quote assuming, and which of those assumptions is most likely to be wrong? |
| How long will it take? | An estimate measured along the happy path. | What do you need from us, and by when, for that date to survive? |
| Do you build native or cross-platform? | A house preference, usually the one they already staff for. | How much of our app would not be shared between the two platforms? |
| Who will be working on it? | Names, which can change the week after you sign. | Who is on this account in month six, and what happens to our project when they leave? |
| Do you use AI? | A yes. Everybody says yes. | Where in this app does a model decide something, and what happens when it decides wrong? |
| Do you offer support afterwards? | A retainer price. | What is covered when an operating system update breaks the build, and how fast? |
The pattern is the same in every row. The weak question can be answered from a sales deck; the stronger one can only be answered by somebody who has actually run an app for a couple of years.
Who owns what, and why it decides everything later
Ownership is the single most expensive thing to get wrong, and the easiest thing to fix before you sign. It is also the part nobody raises during a friendly kick-off, because nothing about it matters until the relationship ends.
The rule is simple: every account that your app depends on should be in your company's name, with the agency invited in as a member. Convenience is the reason it usually goes the other way, and convenience is not worth what it costs to undo.
| Asset or account | Who should hold it | What it costs you if the agency holds it |
|---|---|---|
| Apple Developer Program account | Your company, with the agency added to the team. | The listing, its reviews and its install base belong to somebody else. A fresh listing starts from zero. |
| Google Play Console account | Your company, with the agency added as a user. | The same, and moving a published app to a different developer account is a formal transfer rather than a setting. |
| App signing keys and certificates | Your company, backed up somewhere you control. | The worst one. Without them you cannot publish an update to the app your customers already have installed. |
| Source code repository | Your organisation, with the agency given access. | A rebuild if the relationship ends badly, and source escrow is slower to invoke than it sounds. |
| Backend hosting and database | Your accounts, with the agency given access. | Your customer data sitting behind somebody else's billing relationship. |
| Push, analytics, error reporting and payment accounts | Your accounts. | Quiet failures at the worst time, because the renewal notice goes to an inbox you cannot see. |
| Design files | Yours, in a format you can open without their licence. | Paying a second time for screens you have already bought. |
Both stores document moving an app between developer accounts as a formal process with its own requirements, not a toggle: Apple publishes an overview of app transfer and Google a guide to transferring apps to a different developer account (both checked 23 September 2026). It is doable, and it is not something you want to discover you need.
None of this implies distrust. A company that already works this way will agree in a sentence, and one that resists has told you something useful for free.
Freelancer, small studio or larger agency
The right shape of supplier depends far more on what happens after the first release than on the build itself. All three can produce a working app.
- A freelancer is the cheapest route to a first version and the riskiest route to a maintained one. One illness or one better offer and the project stops, so insist on the ownership list above before anything else.
- A small studio is usually the sweet spot for a first app. You talk to the people writing the code, and there is more than one of them.
- A larger agency sells you process and cover, and you pay for both. Ask who is genuinely assigned, because the people in the pitch are often not the people in the sprint.
- An in-house hire starts making sense once the app is a product rather than a project. One developer rarely covers iOS, Android, the backend and the design.
Geography matters less than the things people use it as a proxy for. What actually decides whether a remote supplier works is the overlap in working hours, whether decisions get written down, and whether you hold the accounts. We work this way ourselves, with clients across the US, Canada, the UK, the EU, Australia, New Zealand, Singapore and Japan.
What AI changed about hiring an app company, and what it did not
Producing a screen is now fast. Deciding what that screen should do, and standing behind it in production, is not. That gap is where the difference between two quotes now lives.
So the useful question is not whether a company uses AI. It is what they do with the time it saves them. The honest answers are more review, more testing and a shorter schedule; the answer to be wary of is more scope at the same price, because the reviewing still has to happen somewhere.
If a company is selling AI as a feature of your app rather than of their process, push on it. There is a real difference between a model that drafts something a person confirms and a model that decides something final, and the second one needs a fallback you have agreed in advance.
Our own position on that is set out in what AI-first app development actually means, and the practical consequences for a schedule are in how long an AI app takes to build.
One thing AI has not changed at all: the build approach is still a real decision, and it is worth understanding before anybody quotes. Our guide to choosing between cross-platform and native apps covers the question we get asked first.
How a quote should be shaped
We quote per project rather than from a price list, and so does everybody honest, because an app is not one thing. What you can reasonably expect is a quote with visible seams.
- Discovery priced on its own. Scoping is real work, and a company that gives it away free usually recovers it in the build.
- Build priced against a written scope, with a stated route for changes. Fixed price buys certainty on a fixed scope, and nothing else.
- Maintenance on its own line, not folded into the build or left off entirely.
- Third-party costs named, from developer program fees to whatever the app calls out to every month.
A single number for "an app" hides all four, and it is the shape of quote that produces an argument in month three. More of the questions buyers put to us before signing anything are collected in our plain answers page.
The work that starts on launch day
An app is not a deliverable, it is a thing that runs. Both platforms ship a major operating system release every year, SDKs get deprecated, store policies change, and certificates expire on their own schedule.
So the maintenance conversation belongs in the selection process, not after it. Ask who watches the crash reports, who replies to a one-star review that describes a real bug, and how quickly a fix reaches the stores once it is written. That is the shape of our own ongoing maintenance work, and it is the part buyers most often discover they have not bought.
The other thing worth settling early is what the app connects to. An enquiry taken in an app is worth nothing while it sits in a database nobody is watching, so the plumbing into your CRM setup and management and the workflow automation that follows it up are part of the project, not an afterthought.
If you would rather hand the whole thing over, that is what our AI app development service is for, and the same team builds the AI automation behind it.
Common questions
How much does it cost to hire a mobile app development company?
There is no useful list price, and anybody publishing one is quoting a different app from yours. Cost tracks the number of screens, how much of the app is not shared between iOS and Android, how many systems it has to talk to, and how long you need it maintained. Ask for the quote to be broken into discovery, build and maintenance so you can see which part is actually driving the number.
Should I hire a freelancer, an agency or build in-house?
A freelancer is the cheapest way to a first version and the most fragile way to keep one. A small studio suits most first apps, because you still talk to the builders and there is more than one of them. An in-house team is worth it once the app is a product with a roadmap rather than a project with an end date.
Who should own the Apple and Google developer accounts?
You should, in your company's name, with the development company invited in. It costs nothing to set up that way at the start and it is the difference between changing supplier and starting again. The same goes for the signing keys, without which nobody can update the app your customers already installed.
What should be in an app development contract?
The scope in writing, who owns the code and the accounts, what happens to the work in progress if either side walks away, how change requests are priced, and what support covers after launch. Handover deserves its own clause: what you receive, in what format, and how long they will answer questions about it.
Is a remote or overseas app development company a risk?
Not by itself. The failures people blame on distance are usually failures of overlap, written decisions and access. Agree the hours you share, insist that decisions land somewhere you can both read them later, and hold the accounts yourself, and a remote supplier is no riskier than a local one.
Read next: planning the launch itself, which picks up once you have chosen who is building it.
