I've inherited a lot of agency-built codebases. Most of them were disasters.
Not because the agencies were incompetent. Many were perfectly capable developers. The problem was almost always the same: the founder didn't know what questions to ask upfront, and the agency had no incentive to bring up the uncomfortable stuff.
This isn't a list of gotcha questions to trap bad agencies. It's the stuff I wish someone had told founders before they signed.
"Who exactly will be working on my project?"
Agencies sell you on their best people. The senior architect in the pitch meeting. The portfolio full of polished case studies. Then the contract starts and you're talking to developers you've never met.
This isn't always malicious. Agencies juggle multiple clients. Their A-team gets pulled to urgent fires. Your project gets handed to whoever is available.
Ask directly: Will the people in this room be the ones building my product? If not, who will? Can I meet them before signing?
Some agencies rotate developers constantly. Others assign a dedicated team. Neither is automatically wrong, but you should know which one you're buying.
"What happens to the code when we're done?"
This sounds obvious. You're paying for software, so you own it. Right?
Read the contract. Some agencies retain IP rights until final payment. Others license third-party components that come with ongoing fees. A few use proprietary frameworks that only their developers understand, which conveniently makes you dependent on them forever.
The question isn't just "do I own the code." It's: can I take this code, hand it to any competent developer, and have them understand it and extend it without calling you?
If the answer is no, you're not buying software. You're renting it.
"How do you handle scope changes?"
Every project changes scope. Features get added. Requirements shift. The market moves.
Agencies know this. Their contracts are designed for it. The question is whether the mechanism is transparent or designed to extract maximum fees.
Fixed-price contracts punish scope changes with expensive change orders. Time-and-materials contracts can balloon without clear boundaries. Neither is inherently bad, but you need to understand which one you're signing and what the change process actually looks like.
Ask: What happened in your last three projects when scope changed mid-build? How was it handled? What did clients end up paying versus the original estimate?
Agencies that get defensive about this question are telling you something.
"What does 'done' actually mean?"
The deliverable says "working application." But what does working mean?
Does it include automated tests? Load testing? Security review? Documentation? Deployment to production, or just a handoff of code files?
I've seen "completed" projects delivered as a zip file with no instructions, no tests, and configuration hardcoded for the agency's development environment. Technically working. Practically useless.
Get specific. What artifacts will I receive? What state will the codebase be in? Who deploys it? Who verifies it works?
If the answer is vague, the delivery will match.
"What's your process when things go wrong?"
Every project hits problems. Server crashes. Integration fails. A key developer gets sick. The third-party API changes without warning.
The question isn't whether problems happen. It's how the agency handles them.
Ask about a specific project that went sideways. Not a success story. A failure, or near-failure. What broke? What did they do? What did the client experience?
Good agencies have stories about problems they solved. Great agencies have stories about problems they anticipated and prevented. Agencies that claim nothing ever goes wrong are either lying or haven't done enough projects to know better.
"Who owns the relationship with third-party services?"
Modern apps depend on external services. Payment processors. Cloud hosting. Email providers. Analytics platforms. Authentication services.
These accounts need to be created somewhere. Sometimes the agency sets them up under their own accounts for convenience. Sometimes they use their own API keys for services with usage-based pricing.
This creates a dependency. When the project ends, you need to migrate everything to accounts you control. If you don't know what accounts exist, you can't migrate them.
Ask: What external services will this project require? Who creates and owns those accounts? Will credentials be transferred to us at the end?
The answer should be that you own everything from day one. If not, build the migration into the contract.
"How do you handle security?"
This is where founders get uncomfortable because they don't know what to ask. So they ask nothing and hope for the best.
At minimum, ask these:
Where are credentials stored? (If they say "in the code," run.)
Who has access to production systems?
What happens to access when the project ends?
Do you run any security testing before handoff?
You don't need to understand every technical detail. You need to know they've thought about it. Agencies that get annoyed by security questions often haven't.
"What does support look like after launch?"
The contract usually covers the build phase. But software doesn't end at launch. Bugs surface. Users find edge cases. Integrations break. Hosting needs monitoring.
Some agencies include a warranty period. Some offer maintenance contracts. Some wave goodbye and wish you luck.
None of these is automatically wrong, but you should know which one you're signing up for. And if ongoing support is available, what does it cost? What's the response time? Is it the same team who built it, or a generic support queue?
The worst position is discovering your app is broken at 2am and realizing nobody is contractually obligated to answer your call.
"Can we talk to a recent client?"
References are standard, but most founders don't use them well.
Don't ask "were you satisfied?" Everyone says yes. Ask specific questions:
What surprised you about working with them?
What would you do differently if you started over?
How was communication when things got stressful?
Did the final cost match the original estimate? If not, why?
If they hesitate on any of these, pay attention.
The question most founders forget
"What happens if this relationship doesn't work out?"
Contracts have termination clauses, but founders rarely read them until they need them.
What's the notice period? What do you get if you terminate early? What's the payment obligation? Who owns the work completed so far? Is there a transition period, or do they just stop?
Hoping you won't need this clause is reasonable. Not reading it is not.
Working with an agency and not sure if you're asking the right questions? Or already past that point and dealing with the aftermath? Let's talk. I've cleaned up enough of these to know what to look for.
