I run a small studio, so treat this accordingly. But I have also spent twenty years cleaning up after other people's builds, and the same handful of questions would have saved every one of those clients a great deal of money.
Ask to see real code
The single most revealing request, and one that is almost never made.
Ask: "Can you show me the code from a recent project?" NDAs make this legitimately difficult — but a competent team has an answer. A sanitised repository, an open-source project, a walkthrough on a call, a code sample written for the purpose.
What you are looking for is not whether you understand it. It is whether they are comfortable being asked. Teams proud of their work want to show it. Teams who subcontract to the cheapest available bidder become uncomfortable, because they have not read it either.
If you have a technical friend, have them look at ten minutes of it. Consistency, naming, error handling and tests tell you more than any portfolio.
Who actually writes it
Ask directly: "Who will be writing my code, and are they employed by you?"
The pattern that produces most disasters: you meet impressive senior people during the sale, sign, and the work is done by junior developers or an offshore subcontractor you were never told about. The seniors you met are on sales calls for the next client.
Follow-up questions that surface it:
How many people will be on this, and at what seniority?
Will I be able to talk to the developers directly, or only through an account manager?
Do you subcontract any part of this?
What happens if the lead developer leaves mid-project?
Subcontracting is not automatically bad. Hiding it is. An agency that says "this part goes to a specialist partner we have worked with for three years" is being straight with you.
Honest estimation
Estimates are where you learn the most about how a team thinks.
A worrying estimate: a single confident number, produced quickly, for a project scoped in a one-hour call. Either they did not think, or they are buying the deal and intend to recover it through change requests.
A good estimate: a range, a breakdown by area, stated assumptions, and explicit exclusions. Ideally a short paid discovery to produce it.
Ask what happens when it is wrong — because it will be. "We absorb it" is unrealistic and usually means corner-cutting. "We flag it early, explain why, and you decide" is what a healthy process sounds like.
Also ask what they would cut if you had two-thirds of the budget. A team that can answer well understands your priorities. A team that says everything is essential has not thought about your business.
Handover and ownership
Settle before signing:
Who owns the code? It should be you, on payment, in writing. Some agencies retain IP and licence it back — occasionally legitimate, always something you must know about rather than discover.
Whose accounts are these? Repository, hosting, domain, database, third-party services. All should be in your organisation with the agency invited. The most effective lock-in is not contractual, it is your domain sitting in someone else's account.
What does handover include? Documentation, environment setup, a deployment runbook, architecture notes, and a walkthrough with your team.
The test question: "If we parted ways tomorrow, what would I have?" A good agency answers immediately, because they have done clean handovers. Hesitation is the answer.
Support after launch
Launch is the middle of the project, not the end. Establish:
Is there a warranty period for defects, and how long?
What does ongoing support cost, and what does it include?
What is the response time for a production outage, and is it contractual?
Who holds the on-call phone at 2am?
What happens if you are unavailable — holidays, other clients?
Vague answers here predict a specific future: launch, the team moves on, something breaks in week three, and nobody is obliged to help.
Red flags
No questions about your business. A team that jumps to technology without understanding your customers is building the wrong thing efficiently.
Agreeing to everything. "Yes" to every request, including contradictory ones, means they will discover the conflicts later — on your budget.
Pressure to sign quickly. Discounts expiring this week are a sales tactic, not a project reality.
No written scope. "We'll figure it out as we go" is the beginning of every dispute.
Reluctance to share references you can speak to unsupervised.
A portfolio of sites that no longer exist. Click them. If most are dead or unmaintained, ask why.
Dramatically cheapest quote. Sometimes efficiency. Usually a misunderstanding of the scope, and it surfaces as change requests or abandonment.
Communication that is already slow. During the sale is as attentive as they will ever be.
A question checklist you can copy
Take this to the call:
Who writes the code, at what seniority, and are they your employees?
Can you show me code from a recent project?
How did you arrive at this estimate, and what assumptions is it based on?
What is explicitly out of scope?
What happens when the estimate proves wrong?
Who owns the code and the accounts?
What exactly does handover include?
What is the warranty period, and what does support cost afterwards?
Can I speak to two clients from the last year?
If my budget dropped by a third, what would you cut?
You are not trying to catch anyone out. You are looking for people who answer specifically and without discomfort. Vagueness on ownership, staffing or scope is the reliable predictor of trouble — far more than price.
The best working relationships I have seen started with a client who asked hard questions early. It sets the tone that this is a professional arrangement with expectations on both sides, which is exactly what you want.