Most failed software projects we get called in to rescue have one thing in common: the wrong vendor was chosen for the work. Not because the vendor was bad in absolute terms — usually they were perfectly competent — but because they were a poor fit for that particular client's needs, stage, or temperament.
These are the questions we'd ask if we were on the buying side, and the answers that should give you pause.
Twelve questions worth asking
1. Who exactly will be doing the work?
You want to know which specific people. Not "our team" — names, roles, and how much of their week your project gets. Pitch teams and delivery teams are different in many agencies. Ask the people pitching whether they'll be writing the code.
2. What's your typical engagement shape?
A fixed-price three-month sprint is a very different commitment than an open-ended retainer. Neither is wrong, but understand which one you're signing up for and whether it matches your appetite for change.
3. How do you scope new work?
The honest answer involves some form of paid discovery before a real estimate is written. Anyone giving you a fixed price for a six-month build off a one-paragraph brief is either lying about the price or lying about the build.
4. What do you typically not do?
Vendors that say "anything" are usually less specialised than vendors that say "we don't really do X". The latter have a defined competence; the former are guessing.
5. Can we talk to two of your current clients?
Not testimonials. Actual phone calls with current clients. Most strong agencies will arrange this; agencies that won't are telling you something.
6. Who owns the code, infrastructure, and accounts?
The answer should be "you do, from day one". If the answer involves the vendor's accounts, their AWS, or their GitHub org, push back. Anything else is a hostage situation waiting to happen.
7. What happens when something breaks at 11pm?
Mature partners have a real answer. Less mature ones don't. Production support, escalation paths, and on-call expectations should be part of the contract before you sign.
8. How do you handle change requests?
Software projects always change. The question is whether the vendor handles change as a normal part of the work or as an opportunity for billable surprise. Both models exist; pick deliberately.
9. What's your release cadence?
Weekly, fortnightly, monthly, or "when it's ready" tell you different things about how the team works. Ask. The right answer depends on your business but the speed of "shipping → learning → shipping again" should match.
10. Where do they sit on AI?
Doesn't matter what the answer is — matters that they have one. If their answer is "we'll see what the team feels like", they aren't paying attention to a meaningful shift in the industry. If their answer is "we use Copilot and Claude across the team, here's how", they're current.
11. What's the offboarding process?
What does it look like if the engagement ends? You want a clean handover plan written into the contract, including code, documentation, infrastructure access, and a transition period.
12. What's the team's senior-to-junior ratio?
A pyramid of juniors with a senior at the top works for some kinds of agency work. It's expensive for clients in software where the senior judgement calls — architecture, security, performance — happen daily. We hire senior because it's how we keep delivery quality predictable. Ask what shape your delivery team will be.
Warning signs
A few patterns we'd treat as deal-breakers:
- No written change-control process. Means the variation invoices will surprise you.
- The pitch team isn't the delivery team. Common in larger consultancies. Demand to meet the actual delivery team before signing.
- No questions back. A serious partner is curious about your business. The pitch is two-way or it isn't going to work.
- Lock-in via custom tooling. "We've built our own CMS / framework / hosting platform you'll use." Translation: portable only with our help.
- Slow communication during the sales process. It only gets slower after the contract is signed.
The shape of a healthy first meeting
A good first conversation should leave both sides with a clear sense of fit (or not) and a small list of next steps. If you leave the meeting feeling like you were sold to but not understood, that's a real signal.
We'd rather have an honest conversation where we decline a project than win one we shouldn't have. If you've got an idea and want a senior team's view on it, book a discovery call.
