There are dozens of articles online listing "questions to ask your software agency." Most of them are written by agencies, and most of them are self-serving — designed to make the agency look good when you ask their suggested questions.
This one is different. We're writing from the agency side, and we're telling you the questions that actually matter — including the ones most prospects forget to ask and the ones agencies hope you won't.
If you're evaluating agencies right now, print this list. The answers will tell you more than any sales deck.
Questions about how they work
"What does your delivery process look like, step by step?"
This is the most important question on this list. If the agency can't walk you through their process — from kickoff to deployment — in clear, concrete terms, they don't have one. They're winging it.
A good answer includes specific phases (scoping, design, development, testing, deployment), specific deliverables at each phase, and a clear explanation of when and how you'll see progress. We've published our entire delivery process — that's the level of specificity you should expect.
"How often will I see working software?"
The answer should be "every two weeks" or something equally frequent. If the answer is "at the end" or "when it's ready," that's a red flag. You should never go more than two weeks without seeing a working demo of what's being built.
Agencies that resist frequent demos are usually hiding something — either slow progress, poor quality, or a gap between what you asked for and what they're building.
"How do you handle scope changes?"
Scope changes happen on every project. The question isn't whether they'll happen — it's how the agency manages them. A good answer explains the trade-off process: new work gets evaluated, the client sees the impact on timeline and budget, and a decision is made together.
A bad answer: "we'll figure it out as we go." An even worse answer: "our fixed price covers everything." That second answer means they'll either cut corners or hit you with change orders later. We've written about how pricing models affect this dynamic in detail.
Questions about what you'll own
"Who owns the code when the project is done?"
You should. Full stop. The code should live in a Git repository that you own, with full access from day one. If the agency hesitates on this question, or if they talk about "licensing" the code to you, walk away.
Some agencies use code ownership as leverage — they build your software on their infrastructure, in their repository, and you can never leave without losing everything. This is not a partnership. It's a trap.
"What documentation will I receive?"
At minimum: architecture overview, setup instructions, environment configuration, and a guide for the next developer who'll work on the codebase. If the agency says "the code is self-documenting," that means they don't write documentation.
Documentation is what makes your software maintainable after the agency engagement ends. Without it, you're locked into the agency whether you want to be or not. We cover this in our post on what happens after launch.
"Can I bring this in-house or switch agencies later?"
The answer should be an enthusiastic "yes." A good agency builds software that can be maintained by anyone competent — not just them. That means clean code, standard frameworks, documentation, and full code ownership.
If the agency seems uncomfortable with this question, ask yourself why.
Questions about their technical decisions
"What's your tech stack, and why?"
The specific technology matters less than whether the agency can explain their choice. "We use Laravel because of the ecosystem, the talent pool, and the convention-over-configuration approach" is a good answer. "We use whatever the client wants" is not — it means they don't have a considered opinion.
An agency that changes stack every project is an agency where no two projects share the same patterns, the same deployment pipeline, or the same maintenance approach. That inconsistency costs you. We've explained our own stack decision in detail.
"How do you handle deployment and hosting?"
You want to hear about automated deployments, staging environments, and zero-downtime releases — not "we FTP the files to the server." The deployment pipeline matters because it determines how quickly bugs get fixed, how safely updates are pushed, and whether your users ever see a maintenance page.
"What happens if something breaks in production?"
A good answer includes monitoring (how they detect issues), response time commitments (how fast they act), and an escalation process (what happens if it's critical). A bad answer: "that shouldn't happen." Things always happen.
Questions about the team
"Who will actually work on my project?"
You want names and roles, not "our team." Will it be the same people from start to finish, or will developers rotate on and off? Is the project manager also writing code? Will you have a single point of contact?
The worst-case scenario: you sign because of the senior people you met in the sales process, and your project gets handed to junior developers you've never met.
"Do you use subcontractors?"
Some agencies do, and that's not inherently bad — but you should know. Subcontractors can introduce knowledge transfer issues and may not be available for maintenance later. If the agency subcontracts, ask how they manage quality and continuity.
Questions about money
"Can I see a breakdown of the estimate?"
A single number — "$80,000" — tells you nothing. You need to see how that number breaks down: how many hours for design, development, testing, project management. Which features are the most expensive? Where could you cut scope to reduce cost?
An agency that can't break down their estimate is guessing. And if they're guessing at the estimate, imagine how they'll manage the budget.
"What's not included?"
This question catches more misaligned expectations than any other. Hosting? Not included. Ongoing maintenance? Not included. Content migration? Design revisions beyond two rounds? Third-party service fees? Ask explicitly what's outside the quote.
"What's the total cost of ownership over 3 years?"
Development cost is just the beginning. Add hosting, maintenance, security updates, and ongoing feature work. A $100K build with $20K/year in maintenance is a $160K investment over 3 years. If you're comparing this to a SaaS subscription, make sure you're comparing total costs — not just the build price. Our build vs. buy framework covers this in detail.
Red flags to watch for
Over the years, we've seen patterns that reliably predict project failure. Watch for these:
They can't show you previous work. NDAs are real, but any established agency can show you something — anonymized case studies, screenshots with client permission, or at minimum a credible description of past projects.
They agree to everything. An agency that never pushes back, never says "that's a bad idea," and never suggests alternatives is an agency that will tell you what you want to hear until it's too late.
They won't commit to a process. "We're flexible" and "we adapt to each client" can mean "we don't have a process." Flexibility is good. Having no structure is not.
They rush the scoping phase. If the agency wants to skip straight to development without proper scoping, they're either desperate for revenue or they don't understand the project well enough. Either way, you'll pay for it later.
They can't explain their pricing. If the estimate is a round number with no breakdown, or if they get defensive when you ask how they calculated it, that's a problem.
Use this list
Before your next agency meeting, go through these questions. Write down the answers. Compare them across agencies. The one that gives you the clearest, most honest answers — including the ones you don't want to hear — is probably the right choice.
We've put together a complete set of resources for anyone evaluating a custom software project: how to write a brief, how long projects take, how pricing models work, and what happens after launch. Together, they'll help you go into the agency conversation prepared.
Want to put us through this list? We'd welcome it →