How to Choose an App Development Company

Choosing who builds your app is a decision made with incomplete information, usually by someone who is not technical, based on proposals that all look reasonable. Here is how to make it less of a gamble.

We are a development company, so read this knowing that. We have written it as the checklist we would want applied to us — if a firm cannot pass these, that is useful information regardless of who you eventually hire.

Look at their work, then look harder

Every portfolio looks good, because every portfolio is curated. Push past the screenshots:

• Is it live? Ask for the App Store or Google Play link. Concept work and unreleased projects are not the same as shipping.
• Did they build it, or maintain it? Both are legitimate; they are different skills. Ask which.
• Is anything like yours? Not the same industry necessarily, but the same hard problem. An app that handles money, real-time data or complex permissions is a different exercise from a catalogue.

The questions that reveal the most

“Who owns the code?”

The answer should be immediate and it should be you — source code, design files, and your own App Store and Google Play accounts. Hesitation here, or an app published under the agency’s developer account, means leaving is expensive by design.

“What happens when we disagree about scope?”

Every project has this moment. A firm with a real process describes it: how change requests are priced, who approves them, what happens to the timeline. A firm without one says it never happens.

“Who exactly will work on this?”

A common pattern is senior people in the sales meeting and juniors on the project. Ask who writes the code, how many projects they run in parallel, and whether the people you are meeting will still be involved in month four.

“What are the overlap hours?”

Not “where are you” — how many hours per day can we talk in real time? A team eight to twelve hours away turns every question into a next-day answer, and a project is made of hundreds of small questions.

“What would you talk us out of?”

The most revealing question on this list. A partner who has built enough products has opinions about which features are traps. Someone who agrees with everything in the first meeting will agree with everything until the invoice.

How to compare quotes that are not comparable

Three proposals with three different numbers are usually three different scopes. Before comparing:

• Is the admin side included? Someone has to manage users, content and rules. That back office is often half the real work and the most common silent omission.
• Are integrations itemised? “Integrates with your systems” is not a line item. Each external system is its own small project.
• What happens after launch? Store submission, bug fixes, the first weeks of real use. If not mentioned, it is not included.
• Is it fixed or an estimate? Ask directly, and ask what makes it change.

The cheapest quote is frequently the one with the most missing from it. Comparing them properly is not about price, it is about making all three describe the same product.

Red flags

• A quote given before anyone mapped your requirements.
• Reluctance to name the people doing the work.
• No mention of what happens after launch.
• A portfolio of concepts rather than released products.
• Pressure to sign before you have talked to anyone else.
• Agreement with every idea you propose.

Talk to two or three, properly

One conversation gives you no reference point; six gives you noise. Two or three real discovery conversations will teach you more about your own project than any amount of internal planning, because each firm will ask questions you had not considered.

If you want one of those conversations to be with us, we will use it to understand what you are building rather than to pitch. See how we work, what we have shipped, or what to prepare before the call.