Choosing a mobile app agency: criteria, questions and pitfalls

You sent your project to four agencies. You receive three quotes, the most expensive of which is more than three times the cheapest. The fourth agency does not reply. The three documents do not describe the same thing, do not use the same vocabulary, and none of them says clearly what is not included.

This is the normal situation, not the exception. Choosing a mobile development agency is not about finding the right price, but about understanding what each price actually buys and which risks it leaves with you. This guide gives the evaluation grid we would apply ourselves if we were on the other side of the table, whether you are looking for an agency in Paris, in the regions or among our offices and areas of operation in France (in French).

What really sets two agencies apart

Almost all agencies display the same technologies, the same promises of an "agile method" and the same logos. What sets them apart shows up elsewhere.

Published apps you can download

A portfolio of images proves nothing: a mock-up can be drawn in an afternoon. Ask for apps that are live on the App Store and Google Play, install them, and look at:

• the ratings and, above all, the date of the last update: an app abandoned for two years says something about the client relationship;
• how smooth the first launch, the sign-up and the offline behaviour are;
• the consistency between the iOS version and the Android version.

Also ask how much of the project the agency really delivered. "We worked on" can mean the complete design just as easily as three weeks of extra help on one screen.

The quality of the scoping, even before the quote

The best indication of what the project will be like is how the agency handles your request before pricing it. A serious agency asks uncomfortable questions: who the users are, which journey proves the value of the product, what already exists on the information-system side, who will maintain the app in two years.

An agency that sends a quote detailed down to the last cent within 48 hours, with no discussion, based on a two-page brief, has either underestimated or padded. Either way, it priced its own assumption, not your project. If your brief is thin, our guide to writing a mobile app requirements document will help you make it comparable.

The real team, by name

Ask the question bluntly: who, concretely, will write the code? Agency employees, freelancers, a subcontracted team abroad? None of these answers is disqualifying in itself. What is disqualifying is not knowing before you sign.

Ask to meet the project manager and the lead developer, not just the salesperson. And ask what happens if one of them leaves the agency during the project.

The five questions to ask before signing

The fourth question is the most revealing. An honest quote says what it does not cover: back office, hosting, maintenance after the warranty, content, translations, store fees. A quote that lists no exclusions is not more generous; it simply moves the discussion to the moment when you are already committed.

Pitfall 1: code ownership

This is the most costly and least visible pitfall. Under French law, software developed by a provider belongs to its author until an assignment of rights has been signed. Paying for the service is not enough to become the owner of the code.

A valid assignment must be written and must specify the rights assigned (reproduction, modification, adaptation, exploitation), their extent, their duration and their territory. A vague formula such as "the client owns the deliverables" leaves the door open to disagreements on the day you want to change provider or take development in-house.

Three practical points, just as important as the clause:

1. The code lives on a Git repository that belongs to you (GitHub, GitLab or equivalent), with access from the first sprint, not "at final delivery".
2. Reused components are identified. An agency often has an in-house technical foundation; that is legitimate, but it must be either assigned or covered by a clearly defined perpetual licence.
3. The infrastructure is in your name: hosting, domain name, database, third-party services (notifications, payment, analytics). A server in the agency's name means an app you cannot move.

Pitfall 2: App Store and Google Play accounts

Publishing an app requires an Apple developer account (annual subscription) and a Google Play Console account (one-off registration fee). Many agencies offer to publish "on their account" to save time. It is a bad idea.

An app published on a third party's account belongs, as far as the stores are concerned, to that third party. Transferring an app from one account to another is possible, but it requires the cooperation of the account holder and technical conditions to be met. The day the relationship becomes strained, you discover that your app, its reviews and its download history are in someone else's hands.

Good practice:

• open the accounts in your company's name (an Apple organisation account requires a D-U-N-S number, so allow a few days to obtain it);
• invite the agency with the rights needed for publishing, revocable at any time;
• keep control of the certificates, the signing keys and the login credentials.

At 55 · agency, accounts are systematically opened in the client's name. It is a contractual commitment, not an option. For what comes next, namely Apple's review and the frequent rejections, see our article on publishing on the App Store and Google Play.

Pitfall 3: fixed price or T&M, poorly chosen

A fixed price is reassuring: one price, one scope, one date. But it does not remove the risk; it makes you pay for it up front in the form of a safety margin, and turns every late clarification into a change order.

For a first app, a capped budget with a scope prioritised on three levels (essential, important, nice to have) is the healthiest compromise: the agency commits to a maximum amount, and you decide what goes into it. The detail of the three models, with their effects on the final invoice, is in our article fixed price, time and materials or capped budget.

Whichever model you choose, one rule protects you: every new request during the project replaces another of equal effort, unless there is an explicit decision to increase the budget.

Reading a quote: what the price gap hides

Let us return to the three quotes from the introduction. For a full iOS and Android app, allow three to four months of work; an MVP on one platform, much cheaper, is delivered in four to eight weeks. Our low prices and plans are detailed on the mobile app pricing page.

When a quote is far below the others, look for what is missing. The items most often absent:

• the back office: the app is priced, the tool for managing its content and users is not;
• the back end: the app assumes an "existing" API that does not exist;
• acceptance and testing on real devices, iOS and Android, several screen sizes;
• publication and the back-and-forth with store review;
• the warranty and maintenance: fixes, operating-system updates, library upgrades.

A much higher quote is not necessarily excessive: it sometimes simply includes what the others left out. The only way to compare is to bring the three proposals back to the same list of items. For the full breakdown of a budget, see how much does a mobile app cost in 2026.

One point of attention on technology: an agency that offers only one approach (all native, or all cross-platform) is selling you what it knows how to do, not necessarily what you need. Ask why it recommends Swift and Kotlin, React Native or Flutter for your project.

Local or remote agency?

The question comes up on every project. The honest answer: geographic proximity matters a lot at certain moments, and hardly at all at others.

Where proximity really helps:

• scoping workshops, where journeys are drawn together around a table;
• tests with real users in the field (a warehouse, a shop, a building site, a hotel);
• projects where several internal departments need to be brought on board and convinced;
• moments of tension, which are better settled face to face than over video calls.

Where it matters little:

• the development itself, which can be steered very well remotely;
• weekly follow-up, provided you get a regular demo of the app running, not a table of progress percentages.

The right compromise: an agency able to travel for scoping and key moments, and a rigorous remote follow-up routine for the rest. If you are in the Île-de-France region, our mobile app agency in Paris hosts workshops at our premises; we also work from Cagnes-sur-Mer and Villeurbanne.

Beware, however, of distance that is not disclosed: an agency with a Paris address and a development team that is entirely offshore, without saying so. Again, this is not a problem in itself; it becomes one when you discover it mid-project, at a 7 a.m. meeting or in a specification misunderstanding.

Agency, freelancer or in-house team?

Before comparing agencies with one another, check that an agency is the right format.

• A freelancer suits a limited scope and a client able to steer design, UX and acceptance testing themselves. The main risk: dependence on a single person.
• An in-house team becomes relevant when the app is the core of the business and development will be continuous for years. Its real cost, including payroll charges, recruitment and management, is often underestimated; we detailed it in in-house team or agency: the real cost.
• An agency brings a complete team (product, design, iOS, Android, back end, acceptance testing) that can be mobilised immediately, and continuity if one person leaves.

A hybrid model works very well: the agency builds the V1 and gradually trains an in-house team that takes over. This is precisely where code ownership and documentation make all the difference.

The final evaluation grid

To decide between two or three agencies, score each from 1 to 5 on these criteria, weighted according to your project:

1. Verifiable track record: published, maintained apps, in a field close to yours.
2. Quality of scoping: relevance of the questions, ability to cut the scope rather than enrich it.
3. Transparency about the team: named people, declared subcontracting.
4. Contractual commitments: assignment of rights, store accounts and infrastructure in your name, exclusions listed.
5. Billing model: suited to the real level of uncertainty in the project.
6. After delivery: warranty, maintenance, reversibility.
7. Relationship: responsiveness, clarity of communication, ability to say no.

The last point is underrated. An agency that accepts all your ideas without discussion is not protecting you: it is billing you. The one that tells you a feature can wait for version 2, and explains why, is working for your product.

In summary

Price is only a symptom. What you are really buying is a scoping method, an identified team and commitments that leave you free at the end of the contract. Check the code, the store accounts and the infrastructure before anything else, choose a billing model consistent with the uncertainty of your project, and do not overpay for proximity where it adds nothing. To see how we work from our different locations, see our mobile app agencies in France (in French) and our mobile app development page.

Already comparing several proposals? Send us your project or the quotes you have received via our contact page, or call +33 1 59 13 25 55: we will tell you, free of charge and within 24 hours, what we would quote and what may be missing elsewhere.

Sources

• Article L131-3 - Code de la propriété intellectuelle (in French) — Légifrance
• Numéro D-U-N-S® - Abonnement (in French) — Apple
• Become a member — Apple
• Premiers pas avec la Play Console — Google Play Console