Compare app agencies using evidence of relevant work, delivery responsibilities, testing, ownership and support. Ask clear questions before agreeing a project.
A polished proposal can hide unresolved scope, unclear account ownership or missing testing responsibilities. Those gaps become expensive once a build depends on them. Before choosing an agency, establish the user journey, systems involved and operational owner so each supplier responds to the same problem.
Use this checklist to compare evidence, not sales confidence. Ask for the people, artefacts and contract terms behind each promise. It cannot predict project success, but it can help you identify an unanswered question while there is still time to change the scope or delivery arrangement.
Warning signs to investigate
Unclear delivery ownership. Ask who coordinates design, implementation, testing and decisions, and what you must provide. A dedicated project manager is not essential to every small engagement, but those responsibilities must be assigned. If your team is expected to coordinate them, the proposal should say so.
A process described only as agile. Request a walkthrough from discovery to handover, showing review points, acceptance checks and the treatment of blocked work. Ask to see a redacted example of a brief or test report. A documented process is useful only if the proposed team can explain how it applies to your project.
Proof that cannot be examined. Ask for relevant work the agency is permitted to discuss and what part it performed. References may be limited by confidentiality, so agree an alternative such as a detailed walkthrough or reviewed sample. A restriction is not proof of poor work, but an unsupported claim still needs evidence.
Prices with different assumptions. A lower quote may cover fewer journeys, less testing or different responsibilities; it may also reflect an efficient approach. Ask suppliers to expose exclusions, dependencies and estimated effort before drawing a conclusion. Location or seniority labels alone do not establish the quality of the proposed delivery.
Testing with no owner or evidence. Ask which checks cover the supported devices, access controls, integrations and failed journeys. Establish who reviews results and approves release. A separate QA role may help, but the important question is whether appropriate testing is planned, performed and documented.
No process for changes. The agreement should explain how new requirements are assessed, priced and approved, including their effect on delivery dates. Clarify the difference between a defect against accepted scope and a new feature. Both fixed-price and flexible engagements need this distinction.
Compare the team against your requirements
Look for relevant experience with the user journey, platform and dependencies. An agency may have strong adjacent experience without an identical case study; ask how it will investigate the unfamiliar parts. A large project count is less useful than a clear explanation of the work and evidence it can actually show.
Find out who is expected to perform the work, who reviews it and how substitutions are handled. Ask about the roles involved in your particular scope rather than assuming a large team is better. Confirm any subcontracting and the arrangements for access, communication and continuity.
Test the difficult requirement in the conversation. For example, ask how offline records reconcile, how an AI answer is evaluated or how sensitive data moves between systems. If specialist review is needed, identify who provides it and what is included. A framework name or compliance label is not evidence that the requirement is satisfied.
Assess communication using concrete examples. Does the agency record assumptions, explain trade-offs and identify questions it cannot yet answer? Agree the review cadence, escalation route and expected response arrangements. Sales-stage responsiveness is useful context, but it is not a reliable promise of how every delivery issue will be handled.
Confirm the operational handover. Who owns hosting, developer accounts, source access, deployment and monitoring? Ask which defects are covered after acceptance and which support activities need a separate agreement. A maintenance offer is only useful when its hours, limits and response arrangements are explicit.
Questions to ask before signing
About process: what is the first reviewable output, what decisions does it resolve and what acceptance criteria will we use? Which assumptions need investigation before the build estimate is reliable? How do scope changes and delayed client inputs affect the plan?
About the team: who performs and reviews design, development and testing? Which relevant integrations have they worked with? How are absences, substitutions and unfamiliar technical work handled? Who can make a decision when the client and delivery teams disagree?
About communication: where can we see progress, decisions and open risks? How often will we review working software? Who needs to attend, and how long do they have to respond? What is the route for a blocked decision or an urgent release problem?
About evidence: can you demonstrate a relevant product and explain your contribution? May we speak to a suitable reference with their permission? If confidentiality prevents that, what alternative evidence can we review? Which outcome claims can you substantiate, and over what period?
About commercials: what work, licences and accounts are included or excluded? What triggers a payment milestone? How are cancellation, incomplete work, source ownership and third-party rights handled? What is handed over, and what support continues only under a separate agreement?
Review the work behind the portfolio
A screenshot demonstrates an interface, not the whole implementation. Where access is available, review a relevant journey and ask which version the agency delivered. Separate public client work, confidential examples and illustrative concepts so each is evaluated on the evidence it actually provides.
Try the product on a representative device where permitted. Follow a complete task, including mistakes, loading and navigation. Ask about the constraints behind the implementation and whether the agency still maintains it. A current app may have changed substantially after the agency’s involvement.
Use store reviews to identify questions, not to assign blame automatically. Complaints may concern pricing, operations or later changes outside the agency’s work. Ask whether a recurring technical problem relates to the delivered scope and what evidence shows how it was investigated.
For a claimed outcome, ask for the baseline, measurement period and attribution. Adoption and revenue depend on more than software delivery. A supplier without publishable commercial results may still provide useful evidence through test artefacts, architecture decisions and a clear account of its contribution.
Compare relevance explicitly. List the unfamiliar requirements in your project and ask how the agency will test them. A similar-looking app is not enough if it lacks your permissions, integrations or device constraints. A small technical experiment may be a sensible first engagement where those risks dominate.
Compare the commercial models
Fixed price assigns an amount to agreed work. It helps comparison when deliverables, assumptions, acceptance criteria and exclusions are specific. Ask what happens when a dependency changes or the requested behaviour differs from the brief. A fixed price does not mean every possible feature or change is included.
Time and materials charges for agreed work performed under the contract. Confirm rates, reporting, budget caps and approval rules. Review progress against useful outputs as well as time spent. Flexibility can help uncertain work, but it still needs priorities and a decision about when to stop or re-estimate.
Milestone or sprint pricing groups work into reviewable increments. Clarify whether you are buying a fixed output, a team’s capacity or a mixture, and what happens to incomplete items. Check termination rights, handover and unpaid-work terms rather than assuming you can leave after any review with a fully releasable product.
A retainer reserves an agreed level of ongoing service or capacity. Confirm included activities, unused capacity, response arrangements and exclusions. It may suit maintenance or continued development where responsibilities are clear. No pricing model removes the need for scoped work and an operational owner.
Make the final comparison explicit
Give shortlisted agencies the same brief and questions. Record answers against scope, evidence, proposed team, testing, ownership, dependencies and total expected cost. Follow up on differences before treating the quotes as comparable. Where uncertainty is substantial, compare a bounded discovery or technical review first.
Choose a delivery arrangement your team can evaluate and operate. The strongest proposal makes responsibilities, evidence and unresolved questions visible, alongside the price. Resolve material gaps in writing before committing to the build, and keep the decision record for the people who will approve releases and inherit the product.