Choosing a development agency is mostly an exercise in reducing uncertainty. You cannot evaluate code you cannot read, and every agency’s website says the same things about quality and partnership. What you can do is ask questions whose answers are hard to fake. Here are the ones that reliably separate teams who will do good work from teams who will not.
Questions about how they think
1. “What would you cut from this scope?”
This is the single most revealing question you can ask. An agency selling hours wants your scope to grow. An agency that wants your project to succeed will have opinions about what does not belong in version one. If the answer is “nothing, it all sounds important,” you are talking to a vendor, not a partner.
2. “What is the riskiest part of this build?”
Every project has one – a third-party integration nobody has used, an unclear data model, a performance requirement that has not been tested. A team that has thought seriously about your project will name it in a sentence. A team that has skimmed your brief will talk about timelines.
3. “Tell me about a project that went badly.”
Everyone has one. The useful signal is not the failure, it is whether they can describe their own contribution to it. “The client kept changing requirements” is a non-answer. “We under-scoped the data migration and did not flag it early enough” is a team that learns.
Questions about the work itself
4. “Who exactly will be writing the code?”
Ask for names, seniority, and how much of their week is on your project. The classic agency failure is a senior team in the pitch and a junior team on the build. Ask to meet the people who will actually do the work before you sign.
5. “What does a normal week look like?”
You want to hear about a working cadence: a demo you can see, a written update, a channel where you can ask a question and get an answer the same day. Vague answers here predict vague answers later.
6. “When will I first see something running?”
If the answer is measured in months, be careful. Good teams get something deployed – even something ugly and incomplete – within the first few weeks, because that is when integration problems surface. Long stretches with nothing to look at are where projects quietly go wrong.
7. “How do you handle changes to scope?”
Scope will change; that is normal. What matters is whether there is a defined, unsurprising process for it. Ask what a change request looks like, how it is priced, and how quickly they can tell you the impact.
8. “What is your testing and QA approach?”
You are listening for specifics: automated tests for critical paths, a staging environment, device coverage, someone whose job is to try to break it. “We test thoroughly” means nothing.
Questions about what happens after launch
9. “Who owns the code and the accounts?”
The answer should be: you do, from day one. Your name on the repository, the hosting, the domain, the app store listings, and every third-party service. Agencies that hold these accounts hold you hostage, whether they intend to or not. Get this in the contract.
10. “What does handover look like?”
Ask what you receive at the end: documentation, environment setup instructions, architectural decisions written down, credentials transferred. A good agency plans for the day you no longer need them.
11. “What does support cost after launch?”
Software needs maintenance. OS updates, dependency patches, security fixes, and hosting all continue after the invoice. Get the ongoing number before you commit to the build number.
12. “Can I speak to a client whose project is finished?”
Testimonials on a website are curated. A twenty-minute call with a past client is not. Ask specifically for someone whose project ended – including, if they will offer it, one that did not go perfectly.
Warning signs
- A fixed quote produced from a short brief with no discovery.
- A price dramatically below everyone else’s, which usually means a scope misunderstanding that becomes your problem later.
- Reluctance to name the individuals on the team.
- Pressure to sign quickly.
- No questions asked back at you. A team that is genuinely interested in the problem will interrogate your brief.
A note on comparing quotes
Two quotes are only comparable if they describe the same scope, and they almost never do. Before comparing prices, write down your own list of deliverables and ask each agency to price against that list, calling out anything they consider out of scope. The cheapest quote is frequently the one with the most missing from it.
How we approach it
We would rather tell you a project is smaller than you think, or that you should not build it yet, than take a brief we do not believe in. Our work starts with strategy and discovery for exactly this reason, and you can see how that has played out on real projects.
If you are evaluating agencies right now, put these questions to us. We are happy to be measured against them.
