1. Do they understand the problem?
A partner who starts with a technology list is selling capacity. A partner who asks about users, exceptions, data and decisions is trying to understand the system. Ask them to restate the problem in their own words and name the assumptions they would test first.
2. Can they explain architecture trade-offs?
You do not need to be an engineer to judge this. Ask why they chose a monolith or services, how they handle failure, where data lives and what happens when a dependency is unavailable. Good answers include constraints and costs, not only benefits.
3. Who owns the code and the decisions?
- Source code, repositories and deployment accounts must belong to you or be transferable.
- Licences for third-party components must be documented.
- Architecture decisions and known risks should be written down, not kept in someone’s head.
- Access to cloud, domain and analytics accounts must not depend on one contractor.
4. How do they communicate?
Ask for a sample of a written status update, a technical decision record and a bug report. Clear writing is part of delivery quality. Confirm the language, the meeting cadence and who answers technical questions. Avoid teams that only communicate through a sales contact.
5. How do they test and secure the work?
- Acceptance criteria exist before development starts.
- Automated tests cover the risky logic, not only the happy path.
- Security checks are part of delivery, not a separate promise.
- Backups, error monitoring and rollback are planned before launch.
- Personal data has a defined purpose, retention and access policy.
6. What happens at handover?
A good partner makes themselves replaceable. Ask for documentation, environment setup, deployment steps, a walkthrough and a period of support. If the answer is “you will not need to understand it”, treat that as a warning.
7. Can you start with a bounded engagement?
A short discovery or a paid pilot is usually a better first step than a large fixed contract. It tests communication, evidence and delivery before either side commits to a long roadmap.
8. Verify claims with evidence
Ask for references you can contact, with permission. Look for public code, technical writing or product demos that match the work you need. Do not treat logos, testimonials or certifications as proof on their own; verify what the partner actually did.
See also what drives custom software cost and our custom software services.