1. Check relevant evidence
Look for live products, named client work or detailed case material related to the system type. Ask what the team itself delivered. A long logo strip does not explain the role, complexity or outcome.
2. Listen to the discovery questions
A useful team asks about users, current records, exceptions, data ownership, integrations and what must not fail. Be cautious when a detailed solution and deadline appear before anyone has examined the workflow.
3. Meet the people doing the work
Know who will manage the project, design the workflow, write the software and respond after launch. If sales and delivery are separate, ask how context moves between them.
4. Review the proposed boundary
The proposal should state what is included, excluded and assumed. It should explain the first usable outcome, dependencies on the client and how a scope change will be assessed.
5. Clarify source code, data and accounts
Put ownership in the agreement. Also decide who controls the domain, hosting, cloud project, app-store accounts, code repository, database backups and third-party service accounts. Access should not depend on one person’s private login.
6. Ask how quality is checked
Discuss review, acceptance, representative test data and defect handling in plain terms. For sensitive or high-risk systems, ask how permissions, audit records, backups and recovery will be verified.
7. Understand deployment and support
Launch is a transfer into daily use. Ask about migration, training, monitoring, response expectations, security updates, backup responsibility and how later enhancements are estimated.
8. Compare estimates on equal ground
A low figure may exclude design, migration, hosting or support. A high figure is not automatically safer. Compare assumptions, deliverables, payment stages and the evidence behind the estimate.
Warning signs
- A guarantee of Google rankings, user growth or business returns that the developer cannot control
- Agreement to every feature without questions or trade-offs
- No written answer about source code and data ownership
- A fixed deadline before integrations or old data are examined
- Case studies that cannot explain the company’s actual contribution
- Pressure to replace working systems without checking integration first
A short final interview
Ask each shortlisted team: What would you leave out of the first release? What is the largest unknown? What would make you recommend a ready-made product instead? The quality of those answers is often more useful than another sales demonstration.