Twelve Questions That Reveal Whether a Developer Is Right

Portfolios tell you less than you think

Every supplier shows you their best work, and you cannot tell from a screenshot who did it, whether it was delivered on time, or whether the client would use them again.

The questions below are more diagnostic because they are about process and behaviour rather than output, and because the way someone answers an awkward question tells you how they will behave when the project has one.

The commercial five

1. Who owns the code, the designs and the accounts when we finish? The only acceptable answer is that you do, in writing.
2. Who specifically will do the work? Names, and ideally a conversation with them before signing.
3. What happens if that person becomes unavailable? Listen for a real answer, not reassurance.
4. What is explicitly out of scope? A supplier who cannot answer has not thought about the boundaries.
5. What does support cost after launch, and what does it include? Get the number before you commit, not after.

The delivery four

1. How often will we see working software? Fortnightly or better. Monthly is slow. “At the end” is a warning.
2. How do you handle changes? There should be a process, and it should be described without defensiveness.
3. What could make this project late? Honest suppliers name three things immediately, usually including something you need to do.
4. What testing will exist? Not necessarily exhaustive, but they should have a view on what matters.

The three that reveal character

• Tell me about a project that went badly and what you changed afterwards. Everyone has one. A supplier who claims otherwise is either inexperienced or not being straight with you.
• What would make you turn this project down? Good suppliers have criteria. It also tells you what they think the risks are.
• What do you think is wrong with our brief? The best answer is a specific, slightly uncomfortable observation.

That last question is the most useful one we know. A supplier who says “it all looks fine” either has not read it or will not tell you when something is wrong later.

What good answers sound like

Specific rather than general. Willing to name limitations. Comfortable saying “we would need to look at that before answering”. Talks about your business problem rather than technology choices.

Bad answers deflect, generalise, or answer a different question. Watch particularly for anyone who responds to a scope question with a technology recommendation.

References worth taking

Ask for a client whose project was a similar size and budget to yours, not the flagship one. Then ask that client three things: did the estimate hold, what went wrong, and would they use them again for something bigger.

The second question is the one that matters. Every project has a problem; how it was handled is what you are actually assessing.

Frequently asked questions