7 Questions to Ask Before Signing With a Dev Agency

Founders hire development agencies for legitimate reasons: speed, access to a full team, no hiring overhead, established processes. Many agency engagements go well. But the ones that go wrong tend to go very wrong — missed deadlines, budget overruns, work that cannot be used, and contracts that offer no recourse.

The difference between a good engagement and a bad one is almost always visible in the contract before the project starts. Here are seven questions to ask before you sign.

1. Who will actually be working on my project?

Agencies are sold by senior people and often built by junior people. The partner who gives you a confident proposal in the sales meeting may have no involvement in the day-to-day work on your project. This is not inherently bad — agencies hire junior engineers and train them, and that can be fine. But you should know who is on your team before you start.

Ask: "Can you introduce me to the specific engineers who will be assigned to this project? I'd like to meet them before we begin."

A reputable agency will say yes and arrange a call. If you are told the team will be "assigned after contract signing," or you only ever speak to account management, push harder. The people who build your product are more important than the proposal that described what they would build.

Also ask about continuity: what happens if a key engineer leaves the agency mid-project? Who owns the knowledge transfer? This happens more often than agencies acknowledge.

2. Who owns the code?

This question has cost founders their companies. Many agency contracts default to the agency retaining copyright on work produced, or include vague language about "licensing" the code to you. This means the agency technically owns your product's source code even after you have paid for it.

Ask: "Does your contract include a full IP assignment transferring all intellectual property to us upon payment, with no retained rights?"

The answer should be an unequivocal yes. If there is any hesitation, any mention of "licensing," or any limitation on your rights to use, modify, sell, or build upon the code after the engagement, have a lawyer review the contract before you sign.

This is not a theoretical concern. Founders who discover mid-acquisition that they do not own their codebase face material problems in due diligence.

3. How do you handle scope that was not in the original proposal?

Every project evolves. Requirements become clearer as you build. Users give feedback that changes priorities. Something that seemed simple turns out to be complex. How an agency handles these moments defines whether the engagement is collaborative or adversarial.

Ask: "Walk me through a recent project where requirements changed significantly after you started. How was that handled and how did it affect cost and timeline?"

Listen for whether they describe a clear, transparent process — a formal change order with a cost estimate and timeline impact before any work begins — or whether the answer is vague. An agency that is vague about this in the pre-sales conversation will be vague about it when your budget is already committed.

Also ask for the specific change order mechanism in the contract. How are change orders initiated? Who approves them? What is the pricing mechanism? If "additional work" is billed at an hourly rate, ask what that rate is.

4. What are the acceptance criteria for deliverables?

"We will deliver a working MVP" is not a deliverable. It is a description with no accountability. If the contract does not define what "working" means in specific, testable terms, you have no recourse if the final product does not meet your expectations.

Ask: "Can you show me how deliverables are defined in your contracts — specifically what constitutes acceptance of a milestone?"

Look for: specific features with defined behavior, test criteria or acceptance tests that can be objectively passed or failed, and a revision process that defines how many rounds of feedback are included in the scope.

If the contract describes deliverables in vague terms — "completed mobile application," "functional backend API" — ask for those terms to be made specific before you sign. This conversation is uncomfortable if the agency resists it. That discomfort is a signal.

5. What is the handoff process when the project ends?

The end of an agency engagement is where many founders get surprised. The project is "done," the agency moves on, and you are left with a codebase you cannot change, documentation that does not exist, and no one who understands how the system works.

Ask: "What does your standard project handoff include? What documentation do we receive, how is the codebase handed over, and do you offer a knowledge transfer session with your engineers?"

You should expect: all source code in a repository you own, documentation covering the system architecture and deployment process, a walkthrough session where the developers explain key decisions, and credentials and access for all services and infrastructure.

If the agency's standard handoff does not include these, negotiate them into the contract explicitly. The cost of a proper handoff is far lower than the cost of inheriting a codebase that no one can explain.

6. What happens if we need to terminate the contract early?

Projects end early for many reasons: funding falls through, pivot in direction, the relationship is not working. The contract should protect you in this scenario, not trap you.

Ask: "If we need to end the engagement early, what are our obligations? Do we own everything built up to that point?"

Look for: clear termination notice periods (30 days is reasonable, 90 days is onerous for a startup), payment for work completed rather than the full contract value, and explicit assignment of all work product to you upon payment of amounts owed.

Some contracts include "kill fee" clauses that require payment of a percentage of the remaining contract value on early termination. This is not inherently unreasonable for long-term fixed-price contracts, but the terms should be explicit and proportionate.

7. Can I speak to two or three past clients — specifically ones from projects that did not go perfectly?

References from an agency are curated. You will talk to happy clients. That is still valuable — it confirms that happy clients exist — but it does not tell you how the agency behaves when things go wrong.

Ask: "Can you connect me with a couple of past clients — ideally including at least one project that had challenges or did not go as planned? I'd like to understand how you handled it."

An agency that has nothing but smooth projects to point to either cherry-picks references or has not done enough work to encounter real problems. One that can confidently connect you with a client who experienced scope changes, delays, or technical challenges — and where that client still speaks well of the relationship — is one that has learned to navigate difficulty.

If the agency declines to provide any references or cannot produce a single past client willing to speak with you, that is a definitive red flag.

The Common Thread

These seven questions share a theme: they force explicit answers to things that agency proposals prefer to leave implicit. Good agencies answer all of them directly. They have clear processes, clean contracts, and confidence in their track record. They welcome due diligence because due diligence confirms their quality.

Agencies that hedge, deflect, or produce vague answers to specific questions are telling you something important about what the engagement will feel like when real decisions need to be made.

The time to find this out is before you sign. Get the answers to all seven questions, in writing, before the contract is final. The ones that survive that process are the ones worth working with.