Choose on how a company handles the parts of the job that go wrong, not on price or portfolio. Price tells you what they hope to charge. A portfolio tells you what shipped, never what it cost to get there or how many features died on the way. Both are the easiest things for a weak supplier to look good on.
The five questions below sort suppliers faster than a shortlist and a spreadsheet. They work because a good answer requires having done the work, and none of them can be prepared from a pitch deck.
Why do most app projects still go wrong?
Because the failure is commercial rather than technical, and it happens before anyone writes code. A 2025 longitudinal update in PM World Journal (January 2026) compared Standish Group CHAOS data across a decade and found the rates barely move: on the 2020 to 2024 cycle, 31 per cent of IT projects succeeded, 50 per cent were challenged and 19 per cent failed outright. Roughly one in five is still written off, after ten years of better tools.
Its more interesting finding is that the root cause has moved. In the 2017 analysis the primary cause of failure was poor requirements gathering. In the 2025 update it is data immaturity and governance, with strategic alignment the deciding competency. Suppliers who only sell build capacity are selling the part of the problem that was never the constraint.
What should you ask an app development company?
Ask the five questions below. Each one targets a failure mode we see repeatedly, and each has a recognisable good answer.
- What would you tell me not to build? A supplier who cannot name anything is either not listening or is happy to bill for whatever you ask. The value of a good partner is largely in the reframe, and half of ours is arguing features out of scope, which is the case we make in how many features an MVP should have.
- Who does the work, and will I speak to them directly? Ask for names and roles, and ask who you talk to in week seven when something breaks. Sales-led firms answer this vaguely because the answer is a team you have not met, often in another time zone, a pattern we set out in the real price of cheap offshore development.
- How do you handle a change I ask for in week six? Every project has one. The answer reveals the commercial model: whether change is treated as a variation to be priced and resisted, or as an expected part of the work with a decision process attached. Neither answer is wrong, and you need to know which you are buying before you sign.
- How do you review code your tools generated? Every competent studio now builds with AI assistance, including us. Veracode's 2025 GenAI Code Security Report (October 2025) tested over 100 models across four languages and found AI-generated code introduced security flaws in 45 per cent of tests, with larger and newer models no safer. A supplier who says their tools handle it has told you they do not review it.
- Who owns the code, the accounts and the store listings on day one? Repository access, cloud accounts in your name, and Apple and Google developer accounts you control. If any of that sits with the agency until final payment, you are a hostage rather than a client. This one is a contract term, not a conversation, so get it in writing.
What does a good answer to "who owns the code" look like?
Your name on everything, from the first commit. The repository is yours with the agency granted access, the cloud accounts are billed to you, the store listings are on your developer account, and the contract assigns intellectual property on payment for work done rather than on completion of the whole project.
That last distinction matters when a project stops halfway, which is what happens to roughly one in five. Ownership on delivery of paid work means you keep what you paid for. Ownership on completion means a stalled project takes your asset with it.
How much should it cost, and does the cheapest quote ever win?
Expect quotes on the same brief to differ by a factor of ten, and treat the cheapest as a scoping difference rather than a discount. Someone has read the brief and priced the obvious half; someone else has priced the integrations, the edge cases and the six weeks of store review and compliance work nobody mentions in a pitch. We broke the bands down in what it actually costs to build an app.
One practical marker: ask who handles app store submission and rejection. Apple states that 90 per cent of submissions are reviewed in under 24 hours, and that over 40 per cent of unresolved issues relate to guideline 2.1 on app completeness, meaning crashes, placeholder content and missing demo credentials. A supplier who has shipped properly will talk about this without prompting. One who has not will treat submission as your problem.
Does the supplier need experience in your sector?
Only where the sector carries obligations that change the build. Consumer apps mostly do not need sector experience, and asking for it narrows your shortlist to no benefit. Regulated work is the opposite: in health, compliance with the NHS clinical risk management standard DCB0129 is not optional, and a supplier meeting it for the first time on your project will learn on your budget and your timeline.
Where obligations apply, ask for the artefacts rather than the anecdote. A clinical risk management file, a named safety officer, a completed assessment from a previous project. Our own healthcare work, including PatientGo, exists because those documents already existed.