Seven questions that expose a software agency before you sign

Most agency evaluation is theatre. You ask about industry experience, they show logos. You ask about process, they show a diagram with the word Agile on it. Both sides know the script.

These seven questions are harder to rehearse, because the honest answers require the firm to say something specific about itself.

1. Who exactly will write the code, and can I meet them?

The most common way an engagement fails is that the team you were sold is not the team you get. A principal engineer pitches; three juniors build. It is rarely malicious. The senior gets pulled onto whichever account is on fire, but the outcome is yours to live with.

Ask to interview each engineer before signing. Ask for the names in the statement of work. A firm that will not name people is telling you it intends to assign whoever is free. The same question applies whether you are buying a project or engineers embedded in your team, and the difference between those two models is worth settling before you ask it.

2. What did you find in discovery that we didn't tell you?

This one is unfair on purpose. If a firm has done any real investigation, reading your API docs, looking at your data model, trying your checkout on a throttled connection, it will have found something you did not mention.

“It all looks straightforward” is the wrong answer. Nothing looks straightforward once you have actually looked. A firm that found problems is a firm that did the work, and it is also the firm whose estimate is more likely to hold — see what a discovery should actually produce.

3. Who owns the code and the cloud account on day one?

The answer should be: you do. Code committed to your Git organisation from the first commit, infrastructure in your cloud account, credentials in your vault.

The arrangements to be wary of are the ones where handover is an event rather than a state: code delivered as a zip at the end, infrastructure in the agency's AWS account, a proprietary framework you cannot hire for. Each of those converts a working relationship into a dependency, and dependencies get priced accordingly at renewal.

4. What is in the last 20% that isn't in the estimate?

Feature-based estimates systematically omit the same things: error states, empty states, permissions, admin tooling, data export, and the migration script. None are features. All are required. Together they are roughly a fifth of the work.

Ask directly whether those are in the number. A firm that has shipped anything will know exactly what you mean and will have an answer ready. A firm that looks surprised has just told you the estimate is light.

5. Tell me about a project that went badly.

Every firm with a real track record has one. What you are listening for is whether the account has a cause, a decision, and a consequence, or whether it is a story about a difficult client.

6. How do you handle a change of scope?

Requirements change. That is not a failure, it is what learning looks like. The question is whether the commercial model can absorb it without a fight.

You want to hear a specific mechanism, like a change-order process with a turnaround time, or a fixed-capacity arrangement where the backlog is reprioritised rather than expanded. What you do not want is “we're flexible,” which means the conversation happens later, under pressure, with leverage on their side. Fixed price versus time and materials covers which model absorbs change and at whose cost.

7. What does support look like the week after launch?

Launch is when defects surface, because that is when real users arrive. Ask what happens in that first fortnight: who is on call, what the response time is, whether it is billed, and when the warranty period ends.

Ask separately about month six. Plenty of firms cover the launch window and then go quiet. If nobody is patching dependencies, your software is quietly ageing toward a rewrite — which is what a maintenance and support arrangement exists to prevent.

The pattern behind all seven

Each question is designed so that a specific answer is easy for a firm that has done the work and hard for one that has not. You are not testing knowledge. You are testing whether the pitch is describing a real team with real scars, or a capability deck.