How to Choose an App Development Company (Ask These Questions)

Every app development company's website says the same things: senior team, proven process, happy clients. Portfolios can be rented, testimonials invented, and team pages staffed with stock photos. None of that is evidence. This guide is a due-diligence checklist built around one principle: judge builders by what you can verify yourself, today, without taking anyone's word for anything. We are a builder, so apply it to us first.

Demand proof you can open

The single strongest signal is shipped work you can personally use. Not screenshots, not a showreel, not logos of famous clients: URLs and store listings you can open right now.

• Ask for three things they built that you can use today. Then use them. Broken links, "it was taken down", or NDAs covering everything they have ever made are answers too.
• For app work, install something of theirs. Does it feel finished? Do the store listing, the privacy policy and the app's actual behaviour agree with each other?
• Check that claims match reality mechanically: a company claiming a public GitHub, a live product, or a store presence should survive you clicking those links. If a "live product" page answers with an error, you have learned the most important thing already.

A company that builds its own products and runs them in production is showing you its unsupervised quality bar. That is worth more than any client list, because nobody made them do it properly.

Why headcount is the wrong question

Buyers often ask "how big is your team?" as a proxy for safety. It is a weak proxy, and it is the most commonly inflated number in the industry. Agencies present contractors, partners and a bench of resumes as "our 40 engineers"; you will typically work with two or three people regardless. The better questions:

• Who exactly will work on my product? Names, roles, and whether they built the things in the portfolio you just opened.
• What happens if that person is unavailable? The honest answer involves documentation and code another engineer can pick up, not a promise of infinite staff.
• What have these specific people shipped end to end? Capability is demonstrated by shipped systems, not by seat count.

Ask about the invisible 60 percent

Most of a production app is not the screens; it is the backend, testing and store work underneath. Weak vendors quote the screens. Questions that expose the difference:

• "Who builds and runs the backend?" If the answer is vague, the quote is fiction. Auth, payments verification, notifications and an admin view are where apps actually succeed or fail.
• "How do you test release builds?" The correct answer mentions real devices and release artifacts, because optimised release builds crash in ways debug builds never show.
• "Walk me through your last store rejection." Everyone who ships has been rejected: a data-safety mismatch, a screenshot rule, a permissions question. A vendor with no rejection story has not shipped much, or is not telling you things.
• "What breaks when the network is gone?" A team that has thought about offline behaviour has thought about the app's worst day, not just its demo.

Ownership: the questions that hurt later

• Whose store accounts? The app should live in your Play Console and App Store Connect accounts. If it lives in the vendor's, your app is a hostage to the relationship.
• Who holds the signing keys? Losing control of Android upload keys can mean losing the ability to update your own app. Key custody should be yours, documented.
• Where does the code live? Your repositories, with history, from the first week. "We will hand it over at the end" means you are not the owner during the project.
• Could another team take over tomorrow? The honest test of documentation. A vendor confident in their work will answer yes without flinching, because lock-in is not their retention strategy.

Red flags that end the conversation

• A quote delivered without a written scope. Five bidders without a design doc are pricing five different imaginary apps.
• Guarantees of store rankings, download counts or revenue. Nobody controls these; claiming to is a tell about everything else.
• "Trusted by thousands" with no name you can call, ratings with no store listing to check, awards you cannot find issued.
• An AI feature list with no answer to "what happens when the model is wrong?" Building with AI honestly means engineering for its failures, not demoing its successes.
• Pressure to skip the small paid discovery phase. It is the cheapest test of how they work, and the vendors who refuse it are refusing to be evaluated.

A sane selection process

• 1. Write one page yourself: what the app does, who it is for, what success looks like in a year.
• 2. Shortlist by openable proof, not by portfolio pages. Two or three candidates is plenty.
• 3. Pay for a design doc first. A small fixed-price discovery producing an architecture, scope and estimate you own, whoever builds it.
• 4. Compare quotes against that same doc. Now differences mean something.
• 5. Contract in milestones, with code in your repositories from the start and the right to stop at any milestone.

And since the fairest test of a checklist is whether its author survives it: our shipped work is on the products page with honest status labels, our live products are openable from every capability page, and the engineering write-ups in the guides show the actual record, including the mistakes. If another vendor gives you better evidence, hire them.