Choose an app development partner by checking evidence of relevant work, the people responsible for delivery, and the assumptions behind the proposal. A polished portfolio or a low headline price is only part of the decision. You need to know what will be built, how it will be tested and what happens after handover.
Use the same brief and questions with each candidate to compare answers fairly. This checklist starts a project discussion; it is not a ranking of agencies or a substitute for reviewing the final agreement.
Start with a brief that candidates can estimate
Explain who uses the app, the task they need to complete, the launch platforms and any systems it must connect to. Include the staff workflow as well as customer screens. Identify essential requirements and features you can defer.
Our app planning documents guide helps organise these inputs. Use the MVP worksheet if the scope remains broad.
A feature list alone is not a specification. Describe acceptance criteria: for example, a customer receives clear confirmation when a request is accepted, and an interrupted submission can be retried without creating duplicates.
Check what the portfolio demonstrates
Ask which parts of each example the candidate delivered. Design, implementation, backend work and maintenance may have been handled by different teams. Where public access is available, try the relevant workflow and compare it with your requirements.
A public app demonstrates the product you can inspect; it does not automatically prove a provider's role in every part of delivery. Ask for clear responsibilities without requesting private client material.
Compare proposals using evidence
| Criterion | Question to ask | Useful evidence |
|---|---|---|
| Relevant work | What comparable flow or integration have you delivered? | Demonstrable product and a clear account of the candidate's role |
| Team | Who designs, develops, tests and communicates? | Defined responsibilities and availability |
| Scope | What is included, excluded or uncertain? | Written deliverables and assumptions |
| Technology | Why does this approach fit our requirements? | Requirements comparison and integration experiments |
| Delivery | How do we review progress and request changes? | Milestones, reviews and change handling |
| Testing | Which devices, flows and failure cases are checked? | Project-specific tests and acceptance criteria |
| Handover | Which code, accounts and instructions do we receive? | Handover list and access responsibilities |
| Support | How are defects and new requirements handled? | Support coverage and further-work estimation process |
Record missing evidence rather than turning every answer into an arbitrary score. A critical unmet requirement can matter more than several attractive extras.
Read the estimate's assumptions
Compare proposals for the same platforms, user roles and integrations. Check whether design, backend operations, testing and release work are included. Separate provider charges and ongoing services from development labour. Our app cost guide includes a worked example.
If a candidate proposes a different approach, ask how it satisfies the same requirements. The native versus cross-platform guide helps organise that discussion. A framework name alone does not demonstrate that an integration works on your devices.
Clarify access and responsibilities
Discuss source code delivery, repository access, platform accounts, hosting administration and the credentials needed to operate the product. Ask how dependencies and third-party licences are documented. Check that the final agreement reflects the responsibilities discussed, including ongoing access and support.
Ask how your team reviews working software and reports problems. An estimate that lists dates without acceptance or review steps leaves important decisions unclear.
Recognise a poor fit
Unexplained price differences, unclear delivery responsibility and promises made without examining requirements deserve follow-up. A team may specialise in different work or lack capacity for your timing. Resolve these issues before treating a presentation as evidence of a good match.
Eleventor Design's apps and team information provide context for evaluating our own work. If you have a relevant Android app proposal, share your brief. Include your users, workflow, platforms, timing and existing product so we can discuss whether the scope fits.