How a Fractional CTO Protects Startups from Bad Agency Contracts

Signing a development agency contract is one of the most consequential decisions a non-technical founder can make. Most founders approach it as a business negotiation — price, timeline, deliverables. What they miss is the technical layer: the clauses that determine who owns the code, what happens when scope changes, and whether the product can survive after the agency relationship ends.

Consider this scenario: a founder signs a six-month contract with a development agency. The project delivers on time. The app launches. Six months later, the founder wants to add a new feature and discovers the codebase is built on proprietary tooling they don't have access to. Or the IP ownership clause assigns copyright to the agency until final payment — a payment the founder didn't realise was still outstanding. Or the acceptance criteria were never defined, so "completion" is contested and the agency walks away without fixing critical bugs.

These aren't edge cases. They're patterns that repeat across hundreds of startups every year. And they're almost entirely preventable with the right technical oversight before the contract is signed.

This article provides a framework for evaluating agency contracts from a technical perspective — covering the most dangerous clauses, the red flags that signal trouble, and the process a fractional CTO follows to protect founders from decisions that look fine on the surface but create serious problems downstream.

Why Agency Contracts Carry Hidden Technical Risk

Most agency contracts are written by legal teams to protect the agency. They're designed to look reasonable to a business reader — clear payment terms, milestone schedules, dispute resolution clauses — while embedding technical provisions that non-technical founders don't know to look for.

The risk is asymmetric. The agency's legal and technical teams understand exactly what every clause means. The founder, often without technical background, is evaluating the same document from a business perspective and seeing a different contract.

Most founders sign agency contracts without reviewing the IP ownership clause. That's how they end up building products they don't actually own.

There are three distinct layers of risk in any agency contract:

1. Legal risk — who owns what, when, and under what conditions. This includes IP ownership, licensing, and the conditions under which ownership transfers from agency to client.
2. Technical risk — the architecture decisions baked into the contract. Will the agency use proprietary tools? What happens if the technology stack becomes unmaintainable? Is there a vendor lock-in provision hiding in the technology choices?
3. Operational risk — what happens when things go wrong. How is scope defined? What constitutes acceptance? What is the process for bug fixes versus new features? Who has access to the production environment?

Non-technical founders are generally equipped to evaluate legal risk, or can engage a lawyer to do so. They're rarely equipped to evaluate technical and operational risk without support. That gap is where most agency contract problems originate.

The Six Most Dangerous Contract Clauses

Not every unusual clause is dangerous, and not every dangerous clause is unusual. What follows is a breakdown of the six categories of provisions that create the most significant problems for early-stage startups.

1. Intellectual Property Ownership

The most consequential clause in any development contract. The default in many agency agreements is that the agency retains copyright until full payment is received — sometimes until the final invoice is settled after final acceptance. This can create situations where a founder has paid 90% of the contract value but technically doesn't own their product.

The right structure is an assignment clause that transfers IP to the client upon payment of each milestone, not at final payment. Even better is a "work for hire" arrangement (in jurisdictions that support it) that assigns IP as work is created.

2. Acceptance Criteria and Definition of Done

A contract without specific acceptance criteria is a contract without completion. "The agency will build a mobile application with the features listed in Appendix A" is not an acceptance criterion — it's a description of work. Proper acceptance criteria define the conditions under which the client is obligated to accept a deliverable.

Acceptance criteria should include functional requirements (the feature works as specified), performance standards (load times, error rates), and testing requirements (unit tests pass, security scans clean). Without these, founders find themselves in disputes where the agency considers work complete and the founder considers it unacceptable — with no contractual mechanism to resolve the disagreement.

2. Technology Lock-In

Some agencies build on proprietary tools, custom frameworks, or platforms that only they have expertise in. The contract may not mention this explicitly — the lock-in is embedded in the technical specifications appendix, if one exists at all.

Lock-in is particularly dangerous when it's invisible. A startup that doesn't realise its backend is built on a custom CMS that only the agency supports won't discover the problem until they try to hire an independent developer. By then, the options are to remain dependent on the original agency or pay to rebuild the system.

A two-day technical review of an agency contract can prevent six months of legal disputes and $50,000 in rework costs.

4. Warranty and Defect Liability

Most agency contracts include a warranty period — typically 30 to 90 days after delivery — during which the agency is obligated to fix defects at no additional cost. What varies enormously is the definition of "defect." A narrow definition (only bugs that cause the system to crash) leaves the founder paying for everything that doesn't meet expectations but doesn't technically cause failure. A broad definition (anything that doesn't meet specification) is much better, but only if the specification was clearly defined to begin with.

Acceptance criteria and warranty clauses are deeply interconnected. Vague specifications make warranty claims almost impossible to enforce, regardless of how long the warranty period is.

5. Scope Definition and Change Request Process

Fixed-price contracts require airtight scope definitions. Time-and-materials contracts require clear processes for approving and billing additional work. Either way, the scope section deserves as much attention as the pricing section — often more.

The critical questions to answer in any scope clause:

• Who has authority to approve scope changes?
• What is the process for getting a change request estimate before work begins?
• Is there a cap on change request rates, or can the agency charge any rate for out-of-scope work?
• If scope is disputed, who decides what was "in scope" to begin with?

6. Code Handover and Access Rights

The handover clause defines what the founder receives at the end of the engagement: source code, documentation, access credentials, and deployment instructions. Many contracts omit documentation entirely. Some don't address access to third-party services — cloud accounts, domain registrars, analytics platforms — that were set up during the project in the agency's name.

A complete handover clause should specify: complete source code with version history, deployment documentation, access credentials for all platforms set up during the project, and a defined transition period during which the agency supports incoming developers.

Technical Due Diligence Before Signing

Technical due diligence for an agency contract is different from evaluating a finished product. The goal is to assess what will be built and whether the agency is genuinely capable of building it — before any money changes hands.

Agency Capability Assessment

Review code samples from previous projects. Look for consistency in style (suggests team coding standards), evidence of testing (unit tests, documentation), and use of modern engineering practices (version control, CI/CD pipelines). Ask for a code walkthrough on a relevant example — a professional agency will agree readily; one that refuses should prompt questions about why.

Identify who will actually build the product. Agencies sometimes pitch with senior engineers and deliver with junior contractors offshore. Requesting the CVs or LinkedIn profiles of the specific developers assigned to the project is a reasonable ask that reveals whether the team presented matches the team who will deliver.

Technical Specification as Contract Appendix

Before signing, request a technical specification document. This should describe the architecture, technology stack, third-party services, and deployment approach. When attached as a contractual appendix, it gives the founder grounds to contest a delivery that deviates materially from what was agreed.

A technical specification also surfaces lock-in risks. If the proposed stack includes proprietary tools or unusual technology choices, the specification is the right moment to ask why and to explore whether standard alternatives exist.

Milestone-to-Deliverable Mapping

Map every milestone in the contract to a specific, testable deliverable. "Phase 1 complete" is not a deliverable. "User registration and authentication flow live in staging environment with unit test coverage above 80%" is a deliverable. This process often surfaces scope assumptions the agency and founder have made independently — better to surface them before signing than to discover them six weeks into the project.

Reference Checks With the Right Questions

Most agencies will provide references. The value depends entirely on the questions asked. Instead of "how was it to work with them?", consider: "Did the project deliver on time and on budget?", "What happened when something went wrong — how did they respond?", "Would you hire them again for a similar scope?", and "Did you receive full code ownership and documentation at project completion?"

The Fractional CTO's Role in Contract Review

A fractional CTO reviewing an agency contract is doing something fundamentally different from a lawyer reviewing it. A lawyer looks for legal exposure. A fractional CTO looks for technical exposure — the ways the contract will cause real engineering problems that legal clauses can't retrospectively fix.

Contract Clause Translation

Non-technical founders often don't know which questions to ask about technical provisions. A fractional CTO translates those clauses into business implications: "This IP clause means if you stop paying, the agency retains ownership. Here's what that means for your next fundraising round." Or: "This warranty definition only covers crashes, not anything that simply doesn't meet your expectations."

Technical Specification Review

When an agency provides a technical specification, a fractional CTO evaluates it for soundness. Does the proposed architecture match the product requirements? Are the technology choices appropriate for a startup's constraints — maintainable, affordable, well-supported by a broad developer community? Are there hidden risks in the third-party dependencies?

Negotiation Support

Knowing what to ask for is only part of the challenge. A fractional CTO can attend negotiation discussions and speak directly with the agency's technical lead — a conversation that almost never happens when founders negotiate alone. Many contract risks can be resolved through negotiation rather than rejection: adding an acceptance criteria appendix, amending the IP transfer timeline, or requiring a code escrow arrangement where source code is deposited with a neutral third party.

The agency contract problem isn't about bad agencies. It's about misaligned expectations between technical and business teams that no one identified before the contract was signed.

Risk Assessment and Go/No-Go Recommendation

Not every contract problem can be resolved through negotiation. A fractional CTO's final output is a structured risk assessment: the specific risks identified, the likelihood of each materialising, the estimated cost if they do, and a clear recommendation — proceed with amendments, negotiate specific changes, or walk away from this agency entirely.

Red Flags vs. Green Flags: A Decision Guide

Not all agencies are equal, and not all risky contracts come from bad agencies. The following patterns are consistent enough to serve as reliable signals when evaluating whether to proceed with an engagement.

Red Flags That Warrant Serious Scrutiny

Green Flags That Indicate a Professional Engagement

• Proactive technical specification: The agency offers to produce a technical spec as part of a discovery phase before contract signature.
• Milestone-based IP transfer: IP transfers to the client upon payment of each milestone, not held until overall project completion.
• Named developers on the project: The contract or proposal identifies the specific developers who will work on the engagement, not just the agency's general team composition.
• Clear change request process: The contract defines in concrete terms how scope changes are requested, estimated, approved, and billed.
• Handover deliverables specified: The contract explicitly lists what the agency will deliver at completion — code, documentation, credentials, and a support transition period.
• Willingness to negotiate technical clauses: Agencies that push back hard on any technical amendment — especially IP and acceptance criteria — are often indicating that those clauses serve a purpose they don't want to reveal.

Ongoing Technical Oversight After Signing

Contract review is not a one-time event. The risks identified before signing don't disappear — they evolve as the project progresses. Ongoing technical oversight throughout the engagement is what converts a well-negotiated contract into a well-delivered product.

Milestone Review Checkpoints

At each milestone, someone with technical knowledge should conduct a structured review. This goes beyond checking that features function as described — it includes reviewing code quality, verifying that the build follows the agreed technical specification, and confirming that the deployment environment matches what was contracted. Many agencies will deliver exactly what the milestone definition requires, and no more. If the contract doesn't require code quality review at each milestone, founders are unlikely to receive it without asking explicitly.

Code Repository Access from Day One

Founders should request read access to the code repository at project kickoff. This is a reasonable ask — professional agencies will often provide it proactively. Read access doesn't mean reviewing every commit, but it creates ongoing visibility and prevents the situation where the founder first sees the codebase at handover and discovers it's unmaintainable, undocumented, or built in ways that contradict the technical specification.

Staging Environment Access

Access to the staging environment throughout the project allows for regular functional review and creates a documented record of what was available at each milestone — useful if acceptance criteria are later disputed. Agencies that provide client access to staging as standard practice are generally more confident in their work.

Managing the Final Handover

The handover is where many agency relationships encounter the most friction, even when the development itself went well. A structured handover includes:

• Transfer of all repository access, including all branches and deployment scripts
• Documentation of architecture, deployment process, and environment configuration
• Transfer of all third-party accounts (cloud infrastructure, analytics, email delivery, payment gateways)
• A handover session with the incoming developer or technical lead
• A run-book — documented instructions for common operational and maintenance tasks

Building these requirements into the contract before signing is significantly easier than attempting to enforce them at project completion, when the agency's incentive to cooperate is at its lowest point.

A Framework for Evaluating Any Agency Contract

The goal of contract review isn't to find reasons to reject an agency. It's to ensure that the engagement is structured for success — that expectations are aligned before work begins, risks are understood and mitigated, and the founder retains meaningful control of the product through and after the project.

A practical evaluation sequence for any agency contract:

1. Read the technical clauses first. Before the commercial terms. IP ownership, acceptance criteria, warranty, and handover provisions will have more long-term impact than pricing.
2. Request a technical specification as a contract appendix. If the agency won't provide one, treat it as a significant red flag. If they will, have someone technically literate review it before signing.
3. Map every milestone to a specific, testable deliverable. "Complete" is not a deliverable. "Working user authentication with unit test coverage above 80%, live in staging environment" is a deliverable.
4. Negotiate IP transfer at each milestone, not at project completion. This is standard in well-constructed contracts and most professional agencies will accept this amendment.
5. Require code repository access from day one. This request costs nothing and prevents surprise discoveries at handover.
6. Define handover deliverables explicitly in the contract. Source code, documentation, credentials, and a defined transition support period should all be named.

The common thread across all six steps is specificity. Vague contracts create space for disagreement. Specific contracts reduce it significantly. Every clause that references terms like "completion," "acceptance," or "deliverable" should have a precise, agreed definition — ideally in a separate appendix that the agency's technical lead has also reviewed and signed off on.

Founders who implement this review process consistently report fewer mid-project disputes, more accurate budgeting (because scope is defined before work begins, not after), and significantly cleaner project handovers. The investment is one to two days of structured review before signing — compared to potentially months of dispute resolution, legal cost, and product delay after.