TL;DR: Most agency contracts protect the agency, not the client. CTOs who don't interrogate the fine print end up locked into relationships where switching costs are prohibitive, IP ownership is ambiguous, and the exit clause might as well be written in disappearing ink. Here are 12 questions that surface the real risks before you commit.
The contract nobody reads until it's too late
You've evaluated three agencies. The finalist submitted a strong proposal, their team seemed sharp during the technical interview, and the references checked out. Now their legal team sends a 14-page Master Service Agreement, and your instinct is to skim it, maybe push back on the payment terms, and sign.
That instinct costs companies $50K-$200K in avoidable disputes every year. Not because agencies are predatory (most aren't), but because contracts are where misaligned expectations become legally binding obligations. What the sales conversation left vague, the contract makes permanent.
Here are the questions that actually matter.
The 12 questions
1. Who owns the code — during the project and after?
This sounds obvious, but the answer often isn't. Some contracts transfer IP only upon final payment (meaning if there's a billing dispute, you don't own anything). Others assign IP per milestone. A few retain a license for the agency to reuse "frameworks" or "accelerators" built during your project.
What to demand: Full IP assignment upon payment for each deliverable. The agency can retain rights to pre-existing tools they brought to the project, but anything built specifically for you should be yours. Get this in writing with specific language, not just "work made for hire" boilerplate.
2. What happens if a key developer leaves the project?
Agencies sell you on the team, not just the company. If your lead architect leaves three months into a six-month project, what's the guarantee?
What to demand: Written commitment to replacement timelines (usually 2-4 weeks), a transition period where the outgoing developer is available for knowledge transfer, and your right to approve the replacement. The contract should specify that team changes don't reset project timelines without mutual agreement.
3. How are change requests priced and approved?
According to the Project Management Institute, scope changes affect 52% of software projects. How the contract handles changes determines whether every sprint becomes a negotiation.
What to demand: A documented change request process with fixed pricing formulas (hourly rate × estimated hours), a written impact assessment before any work begins, and a threshold below which changes are absorbed into the existing budget (typically under 4 hours of work).
4. What's the exit clause?
This is the question most CTOs forget to ask until they wish they had. Some contracts have 90-day termination periods with full payment for uncommitted sprints. Others impose early termination fees of 30-50% of the remaining contract value.
What to demand: 30-day written notice for termination without cause. Payment only for work completed and verifiable. A transition assistance period (typically 2-4 weeks) where the agency helps transfer knowledge to your next team. No penalty beyond paying for work actually performed.
5. What does "done" mean?
Does the agency's definition of "delivered" match yours? Some contracts define delivery as code committed to a repository. Others require passing acceptance tests. The gap between these definitions can be months of work.
What to demand: Specific acceptance criteria tied to each deliverable. A defined acceptance testing period (usually 5-10 business days). Clear conditions under which you can reject a deliverable without it being considered a scope change. The contract should distinguish between "code complete" and "production-ready."
6. Who pays for bugs?
Every software project has bugs. The question is whether fixing them is part of the original price or a new billing event. Some agencies include a 30-day warranty; others start the warranty clock from code commit, not from deployment.
What to demand: A minimum 90-day warranty from the date of deployment to production (not from code delivery). Defects in functionality that was specified in the original requirements should be fixed at no cost. Warranty repairs should have defined response times — typically 24 hours for critical bugs, 5 business days for non-critical.
7. How is "hours worked" verified?
If you're working on a time-and-materials basis, how do you know the hours being billed are accurate? Some agencies use automated time tracking; others rely on self-reported timesheets.
What to demand: Access to a project management tool (Jira, Linear, etc.) where you can see task assignments and time logged per task. Weekly timesheet summaries with detailed breakdowns by developer. The right to audit timesheets against code commits and pull request activity.
8. What security and compliance obligations does the agency accept?
If the agency is building software that handles personal data, health records, or financial information, their security practices become your compliance risk.
What to demand: Written confirmation of security practices: code review processes, vulnerability scanning, secure coding standards. Data handling provisions that match your regulatory requirements (GDPR, SOC 2, HIPAA). The right to conduct or commission security audits of the delivered code at any point during the engagement.
9. What's the communication and escalation structure?
Who do you call when things go wrong? Not the project manager's email — the actual escalation path for blocking issues.
What to demand: Named point of contact for day-to-day communication. Defined escalation path with response times: project issues go to the PM (4-hour response), contractual issues go to a named executive sponsor (24-hour response). Regular status meetings at a defined cadence (weekly or bi-weekly, never less).
10. Can you bring in third parties?
Sometimes midway through a project you realize you need a specialist — a security auditor, a UX researcher, a data migration expert. Some contracts prohibit or restrict third-party involvement.
What to demand: The freedom to bring in independent auditors, code reviewers, or supplementary contractors without requiring the agency's permission. The agency should be contractually obligated to cooperate with third-party audits and code reviews.
11. What's included in the handoff?
When the project ends, what exactly do you receive? "Source code" isn't enough.
What to demand: Complete source code with version history. All environment configurations and deployment scripts. Documentation: architecture decisions, API specifications, and setup guides. Access credentials and service accounts. A formal knowledge transfer session (budget 2-3 days for a medium project).
12. How are disputes resolved?
Nobody discusses dispute resolution during the honeymoon phase. But the mechanism matters enormously if a disagreement reaches an impasse.
What to demand: Mediation before arbitration. Arbitration before litigation. A jurisdiction that's reasonable for both parties. And critically — the ability to continue using delivered code while a dispute is being resolved. Some contracts freeze code access during disputes, and that clause alone can make the whole thing adversarial.
Red flags in agency contracts
Even with the right questions, watch for these patterns:
- Auto-renewal clauses that extend the contract by 6-12 months unless you provide written notice 60-90 days before expiration
- Non-compete restrictions that prevent you from hiring the agency's developers — reasonable for 12 months, unreasonable for 24+
- Indemnification asymmetry where you indemnify the agency but they don't reciprocate
- Limitation of liability capped at the fees paid in the last month (should be last 12 months or total contract value)
- Vague force majeure clauses that let the agency delay indefinitely under loosely defined circumstances
The contract as a relationship signal
Here's a perspective most CTOs miss: how an agency responds to your contract questions tells you more about them than any portfolio review. Agencies that welcome due diligence, provide clear answers, and negotiate openly tend to be the same ones that communicate well during projects.
Agencies that push back on reasonable questions, claim "that's industry standard" without explanation, or pressure you to sign quickly are showing you how they'll handle disagreements during your engagement.
Globalbit's approach
We share our standard MSA template before the first call. Every clause is negotiable to a degree, and we walk clients through the key provisions before asking for a signature. Our contracts include 90-day code warranties, full IP transfer upon milestone payments, 30-day termination notice, and a structured knowledge transfer at project close. Because good contracts aren't about protecting one side — they're about removing ambiguity so both sides can focus on building great software. Let's review what a fair contract looks like for your project.