Quick takeaways
- Ask for a discovery document from a previous project, not a portfolio. Portfolios show finished screens. A discovery brief shows how they think.
- Get code ownership in writing before you sign anything. If handover depends on a final payment of an undefined amount, that leverage was built in deliberately.
- Meet the people who'll actually do the work. The team on the sales call is often not the team on the project.
- Ask what they'd refuse to build. A partner who has never talked a client out of something has never prioritized the client's outcome over their own invoice.
- Insist on working demos every sprint. It's the only progress report that can't be wrong.
- Unclear requirements sink more projects than technical difficulty. Ask how they handle the gap between the process on paper and the process in practice.
Most bad agency relationships are visible in the sales process. People just don't know what to look at.
The proposal looks professional. The portfolio has recognizable logos. The team says yes to everything. Six months later the project is late, the scope is different from what anyone remembers agreeing, and nobody can say precisely when things went wrong.
The signals were there. They were in the questions nobody asked.
Here are the ones worth asking, grouped by what they tell you. Some of these we'd struggle to answer well ourselves on a bad day — that's rather the point.
Before the first call: what to look for
1. Do their case studies include numbers?
"We built a platform for a logistics company" tells you nothing. "Processing time dropped from four hours to twenty minutes" tells you they measured, which means they cared about the outcome rather than the delivery.
If every case study is a description of features with no result attached, ask why in the call. The answer is usually either "the client wouldn't let us share" — fair, and they should be able to describe the shape of the result anyway — or silence.
2. Does their own content demonstrate expertise, or just claim it?
Read their blog. Not for polish. Look for whether anyone there has opinions about trade-offs. A team that writes "we use React because it's modern and scalable" is describing a preference. A team that writes about when React is the wrong choice has actually made that decision under pressure.
3. Are there real names anywhere?
Named engineers with titles and public profiles are accountable in a way that "our expert team" isn't. This is the cheapest signal to check and one of the more reliable.
About the work itself
4. Can I see a discovery document from a past project?
The single most useful question on this list. Redacted is fine. A discovery brief shows how they turn a vague business problem into something buildable — the assumptions they surface, the questions they ask, the constraints they write down.
A portfolio shows what the designers produced. A discovery document shows how the team thinks. Ask for it.
5. How do you handle the gap between the documented process and the actual one?
Unclear requirements sink more projects than any technical problem. Research on IT project failure consistently puts poor requirements at the root of the majority of them.
The answer you want involves watching people work — sitting with the team, following a real case through the current system, finding the spreadsheet nobody mentioned. The answer to be wary of is "we'll work from your specification."
6. What would you refuse to build?
A partner who has never talked a client out of something has never put the client's outcome ahead of their own invoice. Every experienced team has a story about recommending an off-the-shelf tool, or a smaller scope, or waiting six months.
If they can't produce one, they either haven't been doing this long or they say yes to everything. Neither is what you want.
7. What's the smallest useful version of this?
You're testing whether they instinctively reduce scope or expand it. Large projects fail far more often than small ones — the difference is stark, not marginal. A team that proposes phasing before you ask has internalized that.
8. What could go wrong with this project?
Ask it directly. A good answer is specific: "Your ERP integration is the risk — if the API is undocumented we could lose a month there." A bad answer is reassuring: "We've done this many times."
The reassuring answer means either they haven't thought about your project specifically, or they have and they're not telling you.
About the team
9. Who will actually work on this?
The people on the sales call are frequently not the people on the project. Ask for names and roles, and ask whether those people are available when your project starts or finishing something else first.
10. Can I meet the technical lead before we sign?
If the answer is no, that tells you something about how the relationship will work. A fifteen-minute conversation with whoever will own your architecture is worth more than the entire proposal document.
11. How many other projects will this team be on?
Some parallelism is normal. A team split across four clients is not. Ask what percentage of their time you're getting and whether that's contractual.
12. What happens if someone leaves mid-project?
Every agency loses people. The question is whether the knowledge lives in someone's head or in documentation, code review history, and a team that's genuinely shared context.
13. Who do I talk to when something's wrong?
One name. Not a ticketing queue, not an account manager who relays messages to engineers. When a launch goes badly at 9pm, you need someone who can actually decide things.
About process and communication
14. What will I see at the end of each sprint?
Working software you can open and use — that's the only acceptable answer. Not a status report, not a percentage, not a burndown chart.
A team demonstrating running software every two weeks cannot hide a problem for long. A team sending written updates can hide one for months, and often does so without meaning to.
15. How do you handle scope changes?
Every project has them. What matters is whether there's a defined process: a written change, a cost and timeline impact, and a decision before work starts. The alternative is discovering in month four that three "small additions" moved your launch date.
16. What do you need from us, and how quickly?
The most common cause of delay on agency projects isn't engineering speed. It's a decision sitting unmade for three weeks.
A good partner will tell you upfront that they need a named decision-maker with real authority and a response time commitment. If they don't raise it, raise it yourself.
17. How do you test?
You want to hear about automated tests, manual QA, and code review on every change — as things they already do, not things they could add. Ask what their test coverage looks like on a typical project. Hesitation here is informative.
18. What are the time zone overlap hours?
If the team isn't local, get a specific number of overlapping working hours and get it in writing. "We're flexible" is not a number. Four hours of genuine overlap works. One does not.
About ownership and what happens after
19. Who owns the code, and when do I get it?
The right answer: you do, from the first sprint, in your repositories and your cloud accounts.
Watch for handover being conditional on a final payment of an undefined amount, or infrastructure living in the vendor's cloud account, or code delivered as a zip file at the end rather than committed continuously to somewhere you control. Each of those is leverage, and it was built in on purpose.
20. What does support look like after launch?
Ask for specifics: is there a warranty period, how long, what does it cover? What do ongoing retainers include and cost? What's the response time when something breaks in production?
Software isn't finished at launch. A partner who hasn't thought about month thirteen is planning to hand you something and leave.
21. What would I need to hand this to another team?
The uncomfortable one, and the one that reveals the most. You want documented architecture decisions, environment setup instructions, and deployment steps — enough that a competent engineer who has never seen the project can run it locally within a day.
A team that has genuinely built for handover answers this easily. A team that hasn't will treat the question as a sign you don't trust them, which is itself an answer.
Answers worth walking away from
They say
What it usually means
"We can start Monday" on a complex build
No discovery, so no real estimate
"We've never had a project go wrong"
They're not telling you the truth, or they haven't done enough work
A fixed price with no discovery phase
The risk is priced in, or the scope will be argued about later
"Our team" with no names
You'll meet the actual team after you sign
Handover "at project completion"
Leverage, by design
Yes to every feature request
Nobody is protecting the timeline
An estimate far below everyone else's
Either scope is missing or it'll be found later through change requests
How to run the comparison
Three agencies is enough. More than that and you're managing a procurement process rather than choosing a partner.
Give all three the same brief. Not a specification — a problem. How they respond to ambiguity is more informative than how they price a fixed scope.
Compare the questions they ask you. The best signal in the entire process. A team that asks about your users, your constraints, and your existing systems is already doing the work. A team that asks only about budget and timeline is qualifying a sale.
Compare discovery approaches, not final prices. You can't meaningfully compare estimates for a project nobody has scoped yet. You can compare how each team plans to find out what needs building.
Call a reference and ask one specific question: what went wrong, and how did they handle it? Every project has a bad month. The answer tells you what the relationship is like when things aren't going well, which is when it matters.
Frequently asked questions
How much should I expect to pay for discovery?
A fixed-price discovery phase typically runs a small percentage of the projected build cost and produces a written brief with a costed timeline. Paying for discovery is a good sign — it means the estimate that follows is based on findings rather than optimism. Free discovery usually means a shallow one.
Is a bigger agency safer than a smaller one?
Not inherently. Larger agencies have more process and more redundancy if someone leaves. Smaller ones often give you more senior attention, because there are fewer juniors to staff a project with. The more useful question is who specifically is doing the work, not how many people the company employs.
Should I hire locally or work with a remote team?
Both work. Remote teams cost less and require more deliberate communication — specific overlap hours, a named point of contact, and demos you actually attend. Local teams cost more and remove the coordination overhead. What matters more than location is whether the working agreement is explicit. Vagueness about time zones is the real risk, not distance.
What if we don't have a technical person to evaluate them?
You need one person internally who understands the process deeply and can make decisions quickly — that person doesn't have to be an engineer. For the technical evaluation specifically, an independent architecture review before signing is inexpensive relative to the build and catches most serious mismatches.
Where this leaves you
The pattern across all twenty-one questions is the same: you're testing whether a team will tell you something you don't want to hear.
The ones who will are the ones worth hiring. They'll tell you the scope is too big, the integration is riskier than you think, or that an off-the-shelf tool would do the job for a tenth of the price. That costs them money in the short term, which is exactly why it's the signal that matters.
If you've worked out whether to build in the first place and want a straight technical read on scope and approach, our custom software development team offers a free consultation. We'd rather tell you the project shouldn't happen than bill you for finding out slowly.