5 Questions to Ask a Software Development Agency Before Signing

Most founders ask the wrong questions when hiring a development agency.

They ask about tech stacks and timelines. They ask for references and portfolios. They nod along when the agency explains their "agile methodology." Then six months later, they're staring at a half-built product, an empty bank account, and a contract that somehow doesn't protect them at all.

The questions to ask a software development agency aren't the polite ones. They're the uncomfortable ones. The questions that make the sales rep pause. The ones that reveal whether this agency will actually deliver or just bill hours until you run out of money.

Here are five questions most agencies hope you never think to ask, and what their answers will tell you.

"What happens to my code if your company shuts down next month?"

Agencies go out of business. It happens more than you'd think, especially with smaller shops. The question isn't whether it could happen. The question is whether you're protected if it does.

You're looking for one specific thing here: source code escrow.

A source code escrow agreement means a neutral third party holds a copy of your code. If the agency goes bankrupt, gets acquired, or just vanishes, you get the code. Without this, you might have a contract that says you own the IP, but no actual way to access it.

What a good answer sounds like: "We use [specific escrow service] and can include escrow provisions in the contract. The code gets deposited at each major milestone. Here's how the release triggers work."

What a red flag sounds like: "Oh, we've been in business for 15 years, that's not going to happen." Or worse: "We can discuss that later." Later means never. And 15 years of history doesn't protect you from next quarter's cash flow problem.

The Berlin SaaS company that paid €120,000 to a vendor who then ghosted them? They probably didn't ask this question either. They ended up spending another €70,000 rebuilding from scratch.

"Show me a project that didn't go well. What happened?"

Every agency has had projects go sideways. Every single one. If they claim otherwise, they're either lying or they haven't been around long enough to hit real problems yet.

The question isn't whether they've had failures. It's whether they learned anything from them.

What a good answer sounds like: "Two years ago we had a healthcare client where we underestimated the compliance complexity. We ended up three months over timeline and ate about 40% of the overage ourselves. Now we bring in compliance review at the scoping stage, not after development starts. Here's what we changed in our process."

They should be specific. They should take some responsibility. They should explain what they do differently now.

What a red flag sounds like: "All our projects are successful." Or the blame-shift: "We had one client who kept changing requirements, so that one ran over." If every failed project is the client's fault, guess whose fault your project will be?

31% of project failures come from unclear or shifting scope. But scope shifts both ways. Good agencies catch scope creep early and have honest conversations about it. Bad agencies just keep billing.

"Can I talk to a client you disappointed?"

Anyone can give you three references who love them. Those references are curated. They're the projects that went perfectly, with clients who are friends of the founders.

The real test is asking to talk to someone who wasn't completely satisfied.

What a good answer sounds like: "Sure. We had a rough patch with [Company X] around timeline expectations. I'll check if they're willing to talk. Fair warning, they'll probably tell you we were slow on the initial handoff, and they'd be right."

This shows confidence. They know not every client is thrilled, and they're not afraid of you hearing about it.

What a red flag sounds like: "We don't think that would be appropriate" or "All our clients are satisfied." Both mean the same thing: they have something to hide.

Here's the thing about references. Even the disappointed client reference will often say something like "Yeah, they screwed up X, but they made it right" or "Communication was rough at first but improved." That's actually more valuable information than "They were great!" repeated five times.

"What's your change failure rate and where can I see your recent sprint data?"

This question does two things at once. It tests whether they track engineering metrics at all. And it tests whether they're willing to be transparent about their actual process.

Change failure rate is simple: what percentage of deployments cause problems that need immediate fixes? Good teams sit around 5-15%. Teams that don't measure it have no idea, and that's the problem.

What a good answer sounds like: "Our change failure rate across active projects last quarter was about 8%. Here's a sample sprint report from a recent project, anonymized. You can see velocity, burn-down, and where we hit blockers."

If they can pull up real data, it means they actually track this stuff. That's a signal of process maturity.

What a red flag sounds like: "We don't really track that formally, but we're very careful." Or: "That's proprietary information." Neither is acceptable. Sprint data isn't a trade secret. Agencies that won't show you how they work don't want you to see how they work.

"What pre-existing code will you use, and what licenses apply to it?"

This is the background IP trap, and almost no one asks about it.

Agencies don't build everything from scratch. They have their own frameworks, libraries, internal tools, and reusable components. That's actually fine. It's often more efficient. The problem is when they don't tell you about it.

Your contract might say you own all the code they write. Great. But it probably doesn't give you ownership of their pre-existing tools. So you end up with a product that depends on software you don't own and may not have the right to use long-term.

What a good answer sounds like: "We'll use our internal component library for the admin dashboard. That stays ours, but you get a perpetual royalty-free license to use it. We'll also use these open-source packages [list]. Here's the license breakdown. Everything we write specifically for you, you own outright."

They should be able to list what's theirs, what's open source, and what's yours.

What a red flag sounds like: "You'll own everything we build." Too vague. Does that include their proprietary authentication module? Their deployment scripts? Their component library? Push for specifics.

This becomes critical if you ever want to switch agencies or bring development in-house. If you can't run the product without their proprietary framework, you're locked in whether you like it or not.

The contract clauses that actually matter

Asking good questions is step one. Getting the answers in writing is step two.

Most dev agency contracts favor the agency. That's not because they're evil. It's because they wrote the contract. So you need to know which clauses to push on.

IP assignment with payment linkage. The contract should specify exactly when IP transfers to you. Smart contracts link this to payment milestones: you pay for milestone two, you own the code from milestone two. This protects both sides.

Exit and transition provisions. What happens if you want to leave mid-project? Good contracts specify knowledge transfer requirements, documentation standards, and a transition period. Bad contracts make leaving so painful you feel trapped.

The warranty period. What's covered after launch? For how long? 67% of development budgets go to post-launch maintenance. If your agency disappears after go-live, you're starting over with someone new at exactly the moment you can least afford it.

Acceptance criteria. How do you formally accept deliverables? Without clear criteria, you can end up in arguments about whether something is "done." Get specific. User acceptance testing periods. Bug severity definitions. What constitutes a blocking issue.

Change order process. Every project has scope changes. The contract should spell out exactly how changes get requested, estimated, and approved. Otherwise you'll get surprised by bills for "extras" you thought were included.

The uncomfortable truth about hiring development agencies

78% of businesses report positive outsourcing experiences. That sounds encouraging until you realize it means 22% don't. And the ones that don't positive? Those are the €120,000 ghost jobs. The $560 million Denver airport disasters. The half-built products sitting in GitHub repos that no one can maintain.

The difference between the 78% and the 22% usually comes down to due diligence. The founders who get working products asked hard questions before signing. The ones who got expensive lessons asked polite questions and accepted polite answers.

Agencies aren't inherently trustworthy or untrustworthy. They're businesses trying to win contracts. The good ones will appreciate that you're asking serious questions. It signals you're a serious client who understands what you're getting into. The bad ones will get defensive or vague.

Either response tells you something.

So before you sign that dev agency contract, ask the questions they hope you won't. Ask about escrow. Ask about failures. Ask for real metrics. Ask to see the parts they don't want to show you.

Because the best time to find out an agency can't answer hard questions is before they have your money.

If you're not sure an agency is telling the truth, an independent technical due diligence review can verify their claims before you commit.