Do they understand the problem and have relevant evidence?
- How will you learn how our users and current process actually work?
- Which assumptions would you test before committing to the full build?
- What comparable problems have you solved, and what can you show or explain?
- Who will work on our project and which parts will be subcontracted?
- What would make you advise us not to build this app?
Relevant evidence does not have to be an identical app in the same sector. Look for clear reasoning, working software, honest limits and an ability to explain why decisions were made.
How will discovery, scope and changes work?
- What will discovery produce, and is it separately priced?
- What is included, excluded and assumed in the proposal?
- How are user roles, business rules and acceptance criteria documented?
- How will we review working software during delivery?
- How are change requests assessed, approved and charged?
- Who makes product decisions and how quickly will you need feedback?
- What can be phased without leaving the first release incomplete?
A supplier cannot remove all uncertainty. They should show how they reduce it and how decisions affect the development timescale and price.
What will you own and need to operate?
| Ask about | Useful detail to establish |
|---|---|
| Source code and intellectual property | Ownership, licence terms, repositories, reusable components and what you receive if the relationship ends. |
| Data | Who controls it, where it is stored, how it is exported, retained, backed up and deleted. |
| Hosting and accounts | Whose names hold domains, cloud accounts, stores, payment services and credentials. |
| Third-party services | Licences, usage fees, limits, supplier terms and what happens if an API changes. |
| Documentation | Operational guidance, deployment information and records needed by another capable supplier. |
How will quality, security and launch be handled?
- Which automated and manual tests will be performed?
- How will permissions, sensitive actions and common security risks be reviewed?
- Which browsers, devices and accessibility needs are in scope?
- Who prepares test data and completes user acceptance testing?
- How are defects prioritised and when does warranty work end?
- What is the migration, rollback and launch plan?
- Who monitors the app and responds if an integration or service fails?
Ask for answers appropriate to the app’s risk. A small internal tool and a customer payment platform should not carry identical assurance, but neither should rely on “we test everything” without a method.
What should you ask about support and ongoing cost?
- What is included immediately after launch?
- How do we report faults and what response arrangements apply?
- What maintenance is proactive and what is charged separately?
- Which hosting, licence, store, API and usage costs are expected?
- How are backups, monitoring and recovery handled?
- How is new development estimated and prioritised?
- What assistance is provided if we move to another supplier?
Use the answers to compare total responsibility, not only build price. The guides to app development cost and costs after launch provide further checks.
Choosing an app developer FAQs
Should I ask every developer for a fixed price?
Ask for a clear commercial model. A fixed build price can work after sufficient discovery; forcing certainty around an unclear scope often produces exclusions, contingency or disputes.
Should I choose the supplier with the most features?
No. Prefer a coherent solution to the right problem. Extra features add delivery and operating cost and can make the important journeys harder to use.
Where can I discuss these questions with Probeck?
Review Probeck App Development, then use this same checklist in the conversation.