Why this matters more than the rate card
The cost difference between development partners is usually smaller than the cost difference between a project that works and one that has to be redone. The questions below are designed to surface how a team actually operates, not how they market themselves.
The questions
Ask these of anyone you are considering, including us.
- What would make you tell me not to build this? A partner who has never talked a client out of something is selling hours, not judgement.
- Who exactly will work on this, and what else are they on? Named people beat a capability deck.
- How will I see progress between now and delivery? The answer should involve working software, not status percentages.
- What happens when we disagree about scope? Every project has this moment. Ask how the last one went.
- Who owns the code, the accounts and the infrastructure? The answer should be you, from day one.
- What does handover look like if we part ways? A good team can describe this without flinching.
- What have you got wrong recently, and what changed as a result? Silence here is the answer.
What good answers sound like
Specific, occasionally uncomfortable, and grounded in real projects. A partner describing a failure and the process change that followed is telling you more about their next project than any case study will.
Vague reassurance is the warning sign. "We're very flexible" and "we follow best practices" are not answers.
