I have spent a good part of my career on both sides of this table: running delivery inside agencies, and later being called in to rescue projects that other agencies left half-finished. The pattern behind almost every rescue is the same. The client asked about price, portfolio, and timeline, and signed. Nobody asked the questions that predict how the engagement behaves at month four, when something has gone wrong.
So here are the questions to ask a development agency before you sign anything. They are not gotchas. A good agency will answer all ten comfortably, and several will respect you more for asking. A weak agency will get visibly uncomfortable around questions three, six, and nine, and that discomfort is exactly the information you paid nothing to obtain.
For each question, I will tell you what a good answer sounds like, because knowing what to ask is only half the skill.
Who Actually Does the Work
1. Who, specifically, will write my code?
Many agencies sell with their senior people and deliver with juniors or subcontractors. Neither is automatically bad, juniors need projects and subcontracting is common, but you are entitled to know. Ask for the actual team composition: how many people, what seniority, and whether anyone on the project is external to the agency.
Good answer: names or at least roles and seniority, stated plainly, with a commitment that team changes will be communicated. Bad answer: "our team will handle it" with no specifics, or visible surprise that you asked.
2. How much of this will be subcontracted or outsourced?
A follow-up worth isolating, because it changes your risk profile entirely. If the agency subcontracts the mobile app to a third party, your project now depends on a company you have never met and have no contract with.
Good answer: honest disclosure, plus an explanation of how they manage quality across subcontractors. Bad answer: denial that later turns out to be false. This one is checkable, ask to meet the team on a call before signing.
3. Can I talk to a client from a project that had problems?
Every agency has a curated reference list. Skip it. Ask instead for a client where things got difficult, a delay, a scope fight, a budget overrun. How an agency behaves under stress is the thing you are actually buying, because every nontrivial software project hits stress.
Good answer: a moment of thought, then a real story and a willingness to connect you. Great agencies are proud of their recoveries. Bad answer: "we have never had a problem project." That is either a very young agency or a dishonest one.
Who Owns What
4. Who owns the code, and when does ownership transfer?
This is the question that generates the most expensive surprises. Some agencies retain IP ownership and license it to you. Some transfer ownership only on final payment. Some build your project on top of their proprietary framework, which means you can never leave them even though you "own" your code.
Good answer: you own all custom code upon payment, stated in the contract, with any licensed or reusable components explicitly listed. Insist on seeing the clause.
5. Where will the code, servers, and accounts live, and in whose name?
I have rescued projects where the domain, hosting, and source repository were all registered under the agency's accounts. When the relationship soured, the client was locked out of their own business systems.
Good answer: everything in accounts you own, cloud, domain, repository, app store, with the agency granted access. If an agency resists this, walk away. There is no legitimate reason for it.
6. If we part ways mid-project, what do I walk away with?
Nobody signs expecting a breakup, which is exactly why you negotiate the breakup terms while everyone is friendly. What do you get for the money paid so far: code, documentation, credentials, design files?
Good answer: a clear exit clause, deliverables handed over pro rata, a defined handover procedure. Bad answer: vagueness, or terms that make leaving so costly it is effectively hostage-taking.
What Happens After Launch
7. What exactly does "maintenance" mean, and what does it cost?
Software is not a building, it degrades without attention: security patches, dependency updates, OS and browser changes, bug fixes. Agencies vary wildly here, from genuine ongoing partnership to a warranty that expires in 30 days followed by silence.
Good answer: a concrete maintenance offering, what is included, response times for critical issues, and honest monthly pricing, typically a meaningful fraction of the build cost per year. Be suspicious of "maintenance is free forever" (unsustainable) and of no maintenance offering at all (they plan to disappear).
8. If your agency vanished tomorrow, could another developer take over from your deliverables?
This tests documentation and engineering hygiene. The honest measure of code quality is not elegance, it is whether a competent stranger can pick it up.
Good answer: yes, and here is what we hand over: repository access, deployment documentation, architecture notes, credentials inventory. Ask to see a sample handover document from a past project. Thin documentation from an agency predicts exactly the trap I described in Documentation: The Unsexy Asset That Saves Your Business, except now you are paying to create it.
How They Communicate, Especially Bad News
9. Tell me about a project that ran late. When did the client find out?
Software estimates are wrong routinely; that is the nature of the work. What separates agencies is not whether delays happen but when you learn about them. The worst pattern in this industry is the green-status report that stays green until two weeks before a deadline that was doomed two months earlier.
Good answer: a specific story where they flagged a slip early, re-planned openly, and gave the client real choices about scope versus timeline. You want an agency whose instinct under bad news is to pick up the phone, not to polish a status report.
10. How will I know, week to week, what is actually done?
"Progress: 70 percent" means nothing. Working software means everything. You want a rhythm where you regularly see the actual product, clickable, testable, even if rough, not slide decks about the product.
Good answer: a fixed cadence, weekly or biweekly demos of working software on a staging environment you can access yourself, plus a shared task board you can read. If the first demo is scheduled for month three, your risk is concentrated exactly where you cannot see it.
The Takeaway
Notice what these ten questions have in common: not one of them is about price, and only one touches the portfolio. Price and portfolio are what agencies prepare to be judged on. These questions probe what they cannot rehearse: incentives, ownership, and behavior under failure.
Practical use: send the list before a meeting, then discuss the answers live and watch for hesitation. Get questions four, five, six, and seven reflected in the actual contract, verbal assurances evaporate precisely when you need them. And treat any single disqualifying answer, agency-owned accounts, no exit clause, "we never have problems," as the gift it is: a cheap warning before an expensive lesson.
The deeper point is that the best engagements stop feeling like procurement at all. When ownership is clean, communication is honest, and the after-launch relationship is real, you have something closer to what I described in Stop Hiring Vendors. Start Choosing Tech Partners. That is the standard worth interviewing for.