How to Interview a Development Agency Before You Commission a Build

Choosing a development agency is one of the most consequential decisions you will make before a build begins. The brief looks good, the portfolio is impressive, and the team seems to get what you are after. But portfolios tell you what an agency has done. They tell you almost nothing about how they work, how they handle pressure, or whether they will be honest with you when the project gets difficult.

And projects do get difficult. Scope shifts, requirements blur, and decisions that felt obvious in week two look questionable by week eight. The agencies that handle this well do not do so by accident. They have processes, habits, and a willingness to say uncomfortable things at the right moment. The ones that struggle tend to say yes too readily at the start and then quietly absorb ambiguity until something breaks.

The pitch meeting is where you find out which kind of agency you are sitting across from. Most clients use it to evaluate price and personality. Those are reasonable things to assess, but they leave the more telling questions unasked. We have seen projects derail not because the agency lacked skill, but because nobody had thought to ask how they manage disagreement, or what their discovery process actually involves, or what happens at the end when the keys need changing hands.

Ask the right questions in the pitch, and an agency will show you exactly who they are under pressure.

This article gives you the questions worth asking, and tells you what good answers look like and what red flags sound like. Use it before you commission anything.

Why the Pitch Is the Right Moment to Ask Hard Questions

Most people treat the pitch as a performance, something the agency does while you watch. You see their work, hear their process described at a high level, and then decide whether you like them enough to move forward. That is a reasonable way to find an agency whose aesthetic matches yours. It is a poor way to find one that will serve you well when the project hits a rough patch.

The pitch is actually the safest moment to probe. The agency is motivated, attentive, and trying to demonstrate their value. If they cannot give you a clear answer to a straightforward process question in the pitch, that answer will not get clearer once the contract is signed. If they become defensive when you push on something, that is the relationship you are buying.

Good agencies welcome hard questions. They have been asked them before, they have thought about their answers, and they see the conversation as a sign of a client who knows what they are doing. An agency that deflects, over-promises, or gives you a sales answer where you wanted an operational one is telling you something worth hearing.

The questions in this article are not designed to catch anyone out. They are designed to surface how an agency actually thinks and works, not how they would like you to think they work. Go in with them prepared, and use the space in between answers to notice how comfortable the agency is with honesty.

How Do You Handle Scope Changes Mid-Project?

Scope change is normal. What varies is whether an agency has a process for managing it or whether they absorb it quietly until the budget and timeline are both underwater. This question tells you which you are dealing with.

A good answer will describe something structured. The agency will tell you how change requests are logged, how impact is assessed against timeline and cost, and how decisions get made. They will be clear that scope changes have consequences and that those consequences are communicated before work proceeds, not after.

A weak answer often sounds reassuring at first. "We are flexible" and "we work collaboratively" are phrases to be cautious of when they come without any supporting structure. Flexibility without process is just a polite word for ambiguity, and ambiguity in a build is expensive.

We saw this pattern on a sports club app project, where every refinement session intended to reduce scope actually made the product larger. Stakeholders used those sessions to introduce requirements they had never previously mentioned, justifying each addition with "of course it needs to do this" or "of course it needs to do that." The refinement process became a mechanism for expansion rather than reduction, and the project grew accordingly. The agency in that situation had no formal change control, so there was nothing to push back against.

Ask a follow-up: "Can you walk me through how a scope change was handled on a recent project?" A concrete answer is a good sign. A vague one is not.

What Happens When Requirements Are Unclear or Incomplete?

No brief arrives complete. There are always gaps, assumptions, and areas where the client has not yet thought something through. The question is whether the agency surfaces those gaps early or builds around them quietly.

Agencies that build around unclear requirements do so for understandable reasons. Raising a gap feels like admitting they did not read the brief properly, or like making the client feel criticised. So they make an assumption, build to it, and then discover somewhere in UAT that the assumption was wrong. Geneca's research found that up to 80% of respondents reported spending half their time reworking software, and a significant proportion of that rework traces back to requirements that were not properly resolved before build began.

A good agency will describe a structured process for resolving ambiguity before it becomes a build problem. They will talk about discovery sessions, documented requirements sign-off, and defined protocols for what happens when something is unclear mid-sprint. They will be comfortable saying "we push back" rather than "we get on with it."

It is also worth asking how they handle situations where the client thinks the requirements are clear but the agency can see gaps the client cannot. That is the harder skill, and the answer reveals a great deal about the working relationship you are about to enter.

Ask the agency to describe a project where they identified a requirement gap that the client had missed. A team that can answer this specifically, with detail about what the gap was and how it was resolved, is demonstrating something real. A team that has to think for a long time or gives a generic answer may not have a reliable process for catching these things early.

How Do You Make Decisions About User Behaviour and Experience?

This question separates agencies that build what clients ask for from those that build what users need. Both types will tell you they are user-centred. The answers reveal whether that is a genuine working practice or a phrase on the website.

A strong answer will describe how user insight is gathered before decisions are made, how that insight informs design choices, and how the team thinks about the emotional experience of using the product, not just the functional flow. An agency that talks only about analytics and click-through rates is measuring behaviour after the fact. That is useful, but it is not the same as understanding what is driving that behaviour in the first place.

When emotions guide design decisions from the beginning, everything becomes more purposeful. Rather than choosing colours and micro-interactions because they look right, there is a real reason behind each choice. The aim is to understand how users will feel at each point in the journey, not just what they will do.

Good UX decisions come from asking how users feel at each step, not just what they click next.

Ask a follow-up: "Can you show me a decision you made on a recent project that was driven by user insight rather than client preference?" The ability to name a specific example, rather than describe a general methodology, is a meaningful signal. A team that genuinely does this work will have no trouble remembering a real instance.

If the agency uses phrases like "intuitive design" without explaining how they know the design is intuitive for the specific users you are targeting, ask them to be more specific. Intuition is not a methodology. Research, testing, and observation are.

How Do You Manage Communication and Progress Visibility?

The moment a client feels they cannot see what is happening with their project is the moment trust starts to erode. By that point, recovering the relationship takes significantly more effort than maintaining it would have done. This question is about understanding what your experience of the project will actually feel like week to week.

Good agencies will describe specific rhythms: how often you meet, what format those meetings take, how progress is tracked and shared, and what you do when something slips. They will have a clear answer about what tools are used and whether you have direct visibility or whether information is filtered through an account manager.

Ask specifically about what happens when progress falls behind. An agency that says "we would tell you immediately" is saying something meaningful, but only if they can describe the mechanism by which that communication happens. Goodwill alone is not a process.

It is also worth asking what your escalation path looks like if you are not happy with progress. Some agencies have a named person for this. Others leave it undefined, which means that when you need it, you are navigating an unclear structure under time pressure. That is not a comfortable position to be in mid-build.

How Do You Handle Disagreements With the Client?

This is the question most clients do not think to ask, and it is one of the most revealing. Every project has moments where the client wants one thing and the agency thinks another approach is better. How that tension is handled determines whether the project benefits from the agency's expertise or simply confirms whatever the client already believed.

An agency that never disagrees with clients is not providing strategic value. They are providing execution, and there is a meaningful difference. You are paying for the agency's knowledge and experience, and that knowledge only becomes useful if they are willing to use it even when it creates friction.

We work this way ourselves. When a client has what they believe is full clarity on a problem but we can see gaps, we ask questions rather than challenging their assumptions head-on. That approach keeps the conversation constructive and means the client arrives at better understanding through their own reasoning, not through being told they are wrong. Even when the outcome of that process is a significant pivot, or in some cases not proceeding with a product at all, it is done with a shared goal of building something that will actually succeed.

A good agency will be comfortable describing a moment where they pushed back on a client and why. An agency that says they always find a way to accommodate the client, or that the client always knows best, is telling you their disagreements happen silently and ineffectively.

What Does Your Discovery Process Look Like?

Discovery is where the quality of what gets built is determined. A thorough discovery process surfaces assumptions, aligns expectations, and defines the problem clearly before any building begins. A thin one produces a brief that looks complete but contains gaps that only appear mid-build.

Ask what discovery involves in practical terms. How long does it take? Who is involved? What gets documented and signed off at the end? What happens if, during discovery, the agency finds that the original brief needs significant revision?

That last question matters particularly. We have a position on this that shapes how we engage from the start. We need clients to have a clearly defined understanding of the problem their product is solving before engagement can be productive. When that clarity is missing, we will say so directly and suggest the client spends more time exploring the space before we proceed. Building without that foundation is expensive for everyone, and a good agency should be willing to say the same.

A pre-launch founder in the football industry once came to us with a colour-coded spreadsheet mapping competitor products, planning to merge several into one. They were visibly excited. When we began asking questions about prospective users, including why someone would choose an all-in-one product over specialist apps, and whether consolidation risked weakening individual features, the mood shifted considerably. That kind of honest exploration is what discovery is for, and an agency that skips it to get to the build faster is not doing you a favour.

Ask the agency what they do when discovery reveals that the original brief was significantly off. A team with real discovery experience will have navigated this before and will be able to describe what that process looked like. If they say it rarely comes up, treat that as a flag rather than reassurance.

How Do You Approach Testing and Quality Assurance?

Testing is the part of a build that gets compressed when timelines slip. An agency under pressure will often deliver something that passes a surface review but has not been tested against the full range of user scenarios, devices, or edge cases. By the time those issues appear, the agency has moved on and you are dealing with them alone.

Ask specifically what their QA process involves, at what stages testing happens, and who does it. Some agencies rely on the build team to test their own work, which creates an obvious problem: the person who built something is the least well-positioned to notice what is missing from it. Dedicated QA, even if partial, produces significantly better results.

Research from the Product Development and Management Association found that organisations with the strongest testing programmes have a 24% failure rate, compared to 46% for those without, according to PDMA. That gap is not small, and it reflects the real cost of treating QA as an afterthought rather than a structured part of the build.

Ask the agency what their definition of "done" looks like, and what sign-off process exists before something moves to the next stage. An agency with clear answers to both questions has built testing into their workflow. An agency that reaches for generalities is probably improvising it.

What Does Handover Look Like at the End of a Build?

Handover is where a surprising number of projects fall apart. The build is complete, the client is ready to take ownership, and then it becomes clear that the documentation is thin, the codebase is not well explained, and the team that built it is already on the next project. The client ends up dependent on the agency for changes they expected to handle internally.

Ask what handover involves in concrete terms. What documentation is provided? Does it cover the codebase, the hosting setup, the deployment process, and the third-party integrations? Is there a formal handover session or is it just a file transfer? What support is available after handover and for how long?

Also ask what access you will have throughout the project. Some agencies treat the codebase as proprietary until the end. Others give you full access from day one. If you are building something you intend to maintain and develop long-term, the latter position protects you significantly better.

The grassroots football product we worked on illustrates what happens when handover never arrives. The founders built based on what they believed the product should do, added complexity at every stage despite our advice to narrow scope, and the product eventually became too complex to complete. More than a year later, there was still no publicly visible release, only repeated "coming soon" announcements. A good agency will tell you, before you commission anything, exactly how and when the work becomes yours.

Red Flags to Watch For in Their Answers

Some things agencies say in pitches sound reasonable but carry warnings worth heeding. Here are the patterns that should prompt a follow-up or a pause.

• They answer every question with enthusiasm and no caveats. Real projects have trade-offs, and an agency that presents none is either inexperienced or telling you what you want to hear.
• They cannot describe a specific example when asked for one. Phrases like "we always do X" or "our process ensures Y" are easier to say than naming a project where it actually happened. Press for the specific instance.
• They become uncomfortable with scope or process questions. An agency that is confident in how they work will engage with these questions directly. One that deflects or becomes vague is revealing a gap.
• They promise certainty. Fixed timelines, fixed costs, and guaranteed outcomes on complex builds are not realistic commitments. An agency that makes them without qualification is either not understanding your project or not being straight with you.
• Discovery is described as brief or optional. A two-day discovery for a substantial build is a flag. Ask what that discovery is actually expected to surface and how that feeds into the brief.
• They have no examples of disagreeing with a client. This is not a sign of harmony. It is a sign of an agency that avoids the conversations that would make your product better.

The silence in investor conversations can be equally revealing. We worked with a pre-investment client whose investor conversations covered technology, marketing, and market size in detail, but never touched on how the product would feel or what user retention targets looked like. The absence of questions was mistaken for approval, when in fact the investors had not understood the emotional dimension of the product at all. Silence in a pitch meeting can carry the same weight. An agency that does not ask questions about your users during the pitch is telling you something about how much they will think about those users during the build.

Conclusion

Commissioning a build is a significant decision, and the pitch is the best opportunity you have to make it a well-informed one. The questions above are not difficult to ask. They are simply direct, and directness is the thing most pitch conversations avoid in favour of a comfortable, mutually agreeable atmosphere that does not always survive contact with a real project.

A good agency will welcome these conversations. They will have clear answers, concrete examples, and an honest account of how they handle the moments that test a project relationship. The ones who do not welcome them are also telling you something useful, and hearing that before a contract is signed is far less costly than discovering it six weeks into a build.

What this process requires from you is a willingness to slow the pitch down. The instinct to move quickly from "I like this agency" to "let's get started" is understandable, but the questions in between those two moments are where the working relationship is actually shaped. Spend time there.

The questions you ask before the contract is signed are the ones that determine what you get built.

If you are approaching a build and want to talk through how to structure the process, assess what you are being told, or understand what a thorough discovery phase should involve, let's talk about your project.

Frequently Asked Questions