Portfolios are curated, references are pre-warmed and every agency says it is a partner. These are the questions that produce answers you cannot rehearse — and the ones whose answers should end the conversation.
Choosing a development partner is mostly an exercise in reading signals, because everything you are shown has been prepared. The portfolio is the best work, the references are the happiest clients, and the proposal was written by someone whose job is writing proposals.
The questions below are useful precisely because they are hard to prepare for. We would be happy to be asked all twelve.
Before the shortlist: get your own house in order
The most expensive projects we see went wrong on the client side first — an unclear owner, a decision-maker who appeared in month three, a brief that changed because it was never written down. Before you approach anyone, settle three things: who decides, what problem this solves in one sentence, and what you will measure a year from now.
An agency cannot rescue a project with no owner. Neither can a better agency.
The twelve questions
1. Who exactly will do the work, and what else are they on?
The people in the pitch are frequently not the people on the project. Ask for names, roles and current commitments. It is not an unreasonable question and the reaction to it is informative on its own.
2. Walk me through a project that went wrong.
Every agency with real experience has one. What you are listening for is whether they can describe the failure specifically, what it cost, and what they changed afterwards. An agency that has never had a difficult project has either not had many projects or is not telling you about them.
3. How do you estimate, and what happens when the estimate is wrong?
Listen for the mechanism, not the confidence. Do they estimate ranges or single numbers? What triggers a conversation about scope? Is a change request a document or an argument? Agencies with a defined process here have been burned and have learned; agencies without one will discover the process during your project.
4. What do I own at the end, and where does it live?
Code repository, hosting accounts, domain, DNS, analytics, CMS admin, design source files. All of it should be in your organisation's accounts, with the agency given access — not the reverse. Any hesitation here is the single strongest reason to walk away.
5. What happens after launch?
Launch is the start of the cost, not the end of it. Dependencies need patching, platforms release breaking changes, and something will break at an inconvenient hour. Ask what maintenance looks like, what the response time is, what is included, and what is billed. An agency that treats ongoing maintenance and support as an afterthought is describing a site that will quietly decay.
6. How do you handle SEO during a rebuild?
The most expensive rebuild failure is a site that launches beautifully and loses half its organic traffic. Ask specifically about the redirect map, URL structure decisions, metadata migration, structured data and a pre-launch crawl comparison. If technical SEO is a separate service they will introduce you to later, it is not in the build plan.
7. What are your performance and accessibility standards?
Good answers name numbers: Core Web Vitals thresholds — LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1 at the 75th percentile — and a WCAG conformance level, usually 2.1 or 2.2 AA. Vague answers about being fast and inclusive mean these will be tested for the first time after launch, if at all. Given ADA Title II deadlines and the European Accessibility Act now in force, accessibility is a legal position as much as a quality one.
8. Show me a project you did not design.
Anyone can make their own design work. Implementing someone else's design faithfully, or extending a system they did not build, is a different and more revealing skill.
9. How do I see progress, and how often?
You want working software at a regular cadence, not status reports. Weekly or fortnightly demos on a real environment. An agency that goes quiet for a month and returns with a reveal is managing your expectations rather than your project.
10. What would you tell me not to build?
The best answer to this question in a sales conversation is a specific, slightly awkward recommendation to cut something. An agency that agrees with every item on your list is pricing the list, not solving the problem.
11. Can I speak to a client whose project did not go smoothly?
A stronger version of the reference request, and a genuine test of confidence. Some will decline for good reasons; the ones who can produce such a reference usually have relationships worth having.
12. What does the handover look like if we bring this in-house?
Documentation, environment setup, a walkthrough, a defined support tail. A partner comfortable with this question is one who expects the relationship to be worth continuing on merit.
Four answers that should end the conversation
- We will host it on our own infrastructure and you cannot have access. This is not hosting; it is a hostage arrangement.
- We do not need a discovery phase, we can start Monday. Speed is not the same as understanding, and a build that starts before the scope is understood ends with a change-request negotiation.
- Guaranteed first-page rankings. Nobody can promise this. It signals either link buying or targets nobody searches for.
- A price that is dramatically below the others with no explanation of scope. Sometimes it is efficiency. More often it is a different, smaller project that will be discovered in month two.
Reading the proposal itself
A proposal is the first deliverable, and it tells you about the working relationship. Look for assumptions written down, exclusions stated plainly, decisions you need to make listed with dates, and a scope that describes outcomes rather than pages. A proposal that reads like a menu of features with no assumptions section is a proposal that has not thought about your project yet.
Beware of hourly-rate comparisons in isolation. The cheaper rate that takes three times as long is the more expensive project, and the more expensive rate attached to a team that has built this exact thing four times is frequently the cheapest way to buy it.
Questions we get asked
Big agency or small? Small teams give you seniority and access; large ones give you redundancy and process. What matters is who is actually on your project and whether they have built something like it before. Ask question one and judge on the answer, not the headcount.
Offshore, nearshore or local? All three produce excellent and terrible work. The reliable predictors are overlapping working hours, a named person accountable for delivery, and communication that survives ambiguity — not geography.
Fixed price or time and materials? Fixed price suits a well-understood scope and pushes risk onto the agency, who will price for it. Time and materials suits genuine uncertainty and requires trust and visible progress. The worst of both is a fixed price on an unclear scope, which is where change-request disputes come from.
What a good first month looks like
The relationship reveals itself quickly, and the first month is a fair sample. Signs it is going well:
- You are asked uncomfortable questions early — about ownership, edge cases, and what happens when data is wrong.
- Something is working and visible within weeks, even if it is small and ugly.
- Assumptions get written down and confirmed rather than absorbed silently.
- Bad news arrives early and specifically. An agency that raises a two-week slip in week three is managing your project. One that reveals it in week nine has been managing your mood.
- Decisions you owe them are tracked with dates. Client-side delay is the largest cause of overrun on most projects, and a good partner makes it visible rather than absorbing it and billing for it later.
If the first month is quiet, agreeable and produces documents rather than software, that is the pattern for the rest of the engagement.
How long should selection take? Long enough for a paid discovery or a small first engagement, which is far more informative than any pitch. Buying a small piece of work before a large one is the cheapest due diligence available.
If you are running this process now, ask us all twelve. We will answer them in writing — and if a smaller maintenance engagement or a discovery phase is the sensible way to test the relationship before a full build, we would rather start there.
Looking for more? Browse all resources.