Evaluate how they define the problem
A capable team can explain the business process, affected users, unknowns and risk in clear language. A long technology list does not replace a useful problem definition.
Request evidence of the process
Review case studies, design artifacts, test practices, release criteria and documentation. Evidence should clarify the team contribution without inventing results or using client names without permission.
Confirm ownership and access
The agreement should define access to source code, infrastructure, domains, analytics, credentials and documentation. Your company should not discover at handover that critical accounts belong only to the supplier.
Understand quality and security practices
Ask how changes are reviewed, environments are separated, dependencies are updated and incidents are handled. The answer should match the risk of the product rather than repeat generic certifications.
Make support conditions explicit
Launch is not the end of product ownership. Define warranty, response channels, maintenance scope, priorities and how new work is estimated before the first production release.
Frequently asked questions
Should a supplier promise a fixed price immediately?+
A fixed price can work for a well defined scope. Immediate certainty around an unclear product usually means assumptions have been hidden rather than removed.
What should a case study prove?+
It should show the context, the team contribution, decisions, constraints and verified outcomes that the client has approved for publication.
How many companies should we compare?+
Compare enough options to understand approach and commercial structure, then spend more time validating the strongest candidates than collecting more quotations.