Five questions that separate a studio from a sales team

The first call with a development company is usually run by someone whose job is to win the work. That is fine — sales is a real skill — but it means the meeting is optimised for the wrong thing. You hear about headcount, awards and logos. None of that tells you what will happen to your project on a Tuesday afternoon in week nine.

The questions below are designed to get past the pitch. None of them are traps, and a good studio will enjoy answering them. What you are listening for is specificity: names, examples, numbers the person clearly did not prepare in advance.

1. “Walk me through your last code review. What did you send back, and why?”

This is the single most useful question you can ask, and the one sales teams handle worst.

A team that genuinely reviews code will answer immediately with something concrete: a pull request that was rejected because it mixed a refactor with a feature, a query that would have loaded the whole table, a missing test for an edge case. They will mention who reviews whose work and roughly how long reviews take.

A weak answer talks about “best practices”, “clean code” or a tool name, and stays general no matter how you rephrase the question.

Follow-up: “Who on the team I would get does the reviewing?” If the answer is a senior engineer who will not be on your project, the practice exists but you will not benefit from it.

2. “Who exactly would work on this, and are they free next month?”

Company size is almost irrelevant. What matters is which people will be assigned, what they have built before, and whether they are actually available.

Good answers name people, or at least roles with real availability: “Two backend engineers finish a project at the end of the month; one of them built our last logistics integration.” Some studios will offer a short call with the proposed lead. That is a strong signal.

Watch for answers like “we will staff the right team once the contract is signed”. Sometimes that is honest capacity planning. Often it means the team does not exist yet and will be hired or subcontracted after you sign — which is how projects end up with a different team from the one in the pitch.

3. “If we had to hit this date with less budget, what would you cut?”

This tests whether anyone has read your brief carefully enough to have an opinion about it.

A good partner will push back on something. They will suggest launching with one user role instead of three, replacing a custom integration with a scheduled import for the first release, or dropping a feature that looks cheap but hides a lot of edge cases. They may also tell you the date is unrealistic, and explain why.

A team that says everything is essential and nothing can move is either not thinking about your project or not willing to disagree with you. Both are problems you will meet again later, at a more expensive moment.

4. “How do you estimate, and what did you get wrong last time?”

Every team underestimates sometimes. The question is whether they know why, and whether their process has changed because of it.

Good answers describe a method — breaking work into tasks, estimating in ranges, adding explicit contingency for integrations or unknowns — and then a real example of a miss: “We underestimated the reporting module because the client’s data had duplicates nobody knew about. We now profile the data before we estimate anything that depends on it.”

Be wary of a team that says their estimates are always accurate. Either they pad heavily, which you pay for, or they absorb overruns by cutting corners you will not see until later.

5. “What happens when we disagree about whether something is in scope?”

Scope disagreements happen on nearly every project. What matters is how they are handled.

A mature studio will describe a process: the disagreement is written down, compared against the scope document, and resolved before the work continues — either as a clarification at no cost, or as a change with its own estimate that you approve before anyone starts. They will usually say the scope document is the reference, not anyone’s memory of a meeting.

If the answer is “we are flexible, we always find a solution”, that sounds friendly and means there is no process. Flexibility without a written reference tends to become an argument once the budget is tight.

What to do with the answers

Take notes during the call and compare them afterwards, not during. Specific answers are easy to verify: you can ask to see an anonymised pull request discussion, speak to the proposed lead, or call a reference about how a scope dispute was handled.

It also helps to ask every candidate the same five questions. The differences between answers are usually more informative than any single answer on its own.

Where this fits in how we work

These questions are part of how partners enter the ANASBRENT network — we ask them of the engineering leads, not the sales team, before any client brief is shared. If you would rather not run this process yourself for every project, tell us what you are building and we will bring you one recommendation with the reasoning written down.