Choosing an app agency or studio: a guide for founders and product owners

Most people who hire an app agency do it once or twice in their working lives. The agency does it every month. That gap in practice is where projects go wrong: in briefs that leave too much open, in proposals that can't be compared, and in contracts that leave the store account, the signing keys or the source code with someone else.

This guide is for founders and product owners commissioning an app for the first time, or for the first time in years. It covers the kinds of partners you can hire, how to write a brief that gets useful answers, how to read proposals side by side, what belongs in the contract and which warning signs to take seriously. It names no companies. The right partner depends on your project, and any list would be out of date within a season.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

Decide what kind of partner you need

"App agency" covers very different businesses, from a two-person development studio to a firm with researchers, designers, developers and marketers under one roof. Before you search, decide which kind of help the project needs. Many projects need two or three of these at different moments, and few firms are equally good at all of them.

The last row costs nothing and is the one people skip. Local developer meetups, founder groups and online communities for iOS, Android and Flutter developers are full of people who have hired agencies and will happily tell you what they'd do differently. Ask them which questions to ask rather than which names to call. You'll learn more, and you'll hear about the problems nobody puts in a portfolio.

Write a brief that gets comparable answers

A brief is how you get proposals you can put side by side. Without one, each agency fills the gaps with its own assumptions, and the three prices you receive describe three different apps. Two or three pages is enough, as long as they're honest about what you don't know yet.

1. The problem and the people: who the app is for, what they do today instead, and why that is annoying enough to make them switch.
2. The core task: the one thing a user must be able to do in the first version. Everything else is a candidate, not a requirement.
3. Features in two columns: needed at launch, and later. Agencies quote the first column; the second tells them where the architecture should leave room.
4. Platforms and constraints: iOS, Android or both, tablets or not, offline use, languages, accessibility expectations.
5. What already exists: designs, a brand, an API, a website, research, or an old app with users you can't afford to lose.
6. Integrations: payments, sign-in providers, maps, a CRM, hardware, anything with its own contract and its own documentation.
7. Budget range and timing. Give a range. It stops proposals pitched at the wrong size, and a good partner will tell you plainly what fits inside it.
8. Who decides: the name of the product owner on your side, and how quickly they can answer questions.
9. After launch: whether you expect the partner to maintain the app, hand it over to your own team, or a bit of both.

If you haven't settled native versus cross-platform, say so in point 4 instead of guessing. A good partner will discuss it with you, and our guide to choosing a cross-platform framework lists the questions worth settling first. For the budget range, the line-by-line breakdown of what an app really costs shows where the hours usually go.

If you can't answer most of the nine points, pay for a short discovery phase before anything else, either with a design studio or as the first paid stage with a builder. Workshops, user flows and a clickable prototype cost far less than building the wrong first version and starting again.

Fixed price or time and materials

Proposals come in two basic shapes, and the number on the first page means something different in each.

A fixed price promises a defined scope for a defined sum. It feels safe, and for a small, well-specified app it can be. The risk hasn't disappeared, though: the agency has priced it in, and the scope document becomes the most important part of the deal, because anything not written there turns into a change request later. Careful agencies offer fixed prices after a discovery phase. Be wary of one that offers a firm price for a one-paragraph idea.

Time and materials means you pay for the hours worked, usually reported per sprint or per month. You keep the freedom to change course as you learn, which is how most apps actually get built, but you carry the budget risk. It works when your product owner reviews progress every week or two and the partner shows working builds rather than status slides.

Many projects end up in between: a fixed-price discovery, then time and materials with an agreed budget cap and a ranked feature list, so the least important features fall off the end if the money runs out. Whatever the model, ask every partner to split the estimate into the same parts (design, app build, backend, testing, project management, release, first year of maintenance) so you can line them up.

When proposals differ a lot, don't average them. Ask the cheapest and the most expensive to walk you through their assumptions. Often one has included a backend, automated tests or a year of updates and the other hasn't. Sometimes the cheapest has simply not read the brief.

Questions to ask in the first conversations

• Which apps that you built can we download today, and what exactly was your part? Store listings usually show the client as the publisher, which is normal, so the answer has to come from the agency.
• Who will work on our project, and are they employees or subcontractors?
• How do you test, on which real devices, and who tests besides the developers?
• How often will we see a working build, and how? TestFlight on iOS and Google Play's internal testing track are the usual routes.
• What happens when Apple or Google rejects a submission?
• How do you change the backend while older versions of the app are still installed on people's phones?
• What does maintenance include, and how do you handle each new iOS and Android release?
• Can we speak to two former clients, one of them from a project that went badly?

The last question is the revealing one. Every agency has had a difficult project. The good ones can tell you what went wrong and what they changed afterward, without blaming the client for all of it.

Red flags

• A firm quote before anyone has asked about your users or read a brief.
• No questions back. A partner who agrees with everything in the first call tends to keep agreeing until the budget is gone.
• An offer to publish the app under the agency's own store account "to keep things simple".
• No mention of testing, accessibility or maintenance anywhere in the proposal.
• Senior people in the pitch who never appear in the project plan.
• Most of the payment due up front, with little tied to delivered milestones.
• Promises of chart positions, download numbers or reviews. Nobody controls the rankings, and both stores forbid paid or incentivized reviews.
• Hesitation about putting the source code in a repository you own from the first week.

One of these on its own may have an innocent explanation. Two or three together usually mean a harder project than it needs to be.

The contract: code, accounts and the exit

The contract is where you protect what is hard to get back later. Have a lawyer read it, and check that it covers the following points in plain words.

Source code and IP

The intellectual property in the work (designs, code, documentation) should transfer to your company on payment. Agencies often keep the rights to their own reusable libraries, which is reasonable as long as you get a permanent license to use them in your app. Ask for the code in a repository your company owns, with the agency's developers invited as collaborators, rather than the other way round.

Store accounts in your name

Enroll your company in the Apple Developer Program and create the Google Play developer account yourself, then invite the agency's people with the roles they need. Apple asks organizations for a D-U-N-S number during enrollment and Google Play verifies organizations too, so start a few weeks before you need the accounts. Apps can be moved between accounts later, but the process has conditions and needs the other party's cooperation, which is exactly what may be missing at the end of a dispute.

Keys and services

Push notification keys, signing certificates, the Android upload key used with Play App Signing, analytics, crash reporting, backend hosting, the domain name, email sending and every third-party API key should sit in accounts you control. Keep a running list during the project instead of reconstructing it at the end.

Handover

Define what you receive when the engagement ends: the repository with its full history, build instructions that someone outside the agency has followed successfully, design source files, credentials and a short period of support for whoever takes over. Write it down while everyone is still on good terms.

Working with a partner abroad

Hiring across borders is ordinary in app development, and it often works well. The problems that do come up are practical ones, and most can be settled before the first sprint.

Start with working hours. You need a few hours of overlap on most working days, and someone on each side who is reachable during them. Agree on one working language for tickets and documents, and make sure the people doing the work use it comfortably, not only the person who ran the sales call. Public holidays differ by country, so ask for the partner's calendar when you plan a release date.

Then the paperwork. Agree which country's law governs the contract and where disputes would be heard, and settle the invoicing currency. VAT on cross-border services is worth a short conversation with your accountant before the first invoice arrives. If the partner will handle your users' personal data, GDPR requires a data processing agreement, and transfers to a country outside the European Economic Area without an adequacy decision need extra safeguards.

Finally, meet properly once. A day together at the start, in person or in a long video workshop, settles more than weeks of messages.

Where to go from here

If you're still working out which roles the project needs, read our guide to the app specialists a project needs, which includes three team shapes for different budgets. If the app is built and you're about to hire promotion help, read finding the angle before you promote an app first, because ASO and PR partners do their best work with a clear position to start from.

And before the first call with any agency, run your feature list through the app development cost calculator and keep the result on the desk beside you. It won't match anyone's quote exactly. It will show you which quotes need the most questions.