Fractional CTO Contract: What Every Agreement Must Cover

The document that looked clean and reasonable at the start of an engagement becomes the source of every dispute about scope, ownership, and exit when things change. The mistake is treating the contract as a legal formality rather than an operational alignment document.

A well structured contract forces the conversations that founders and fractional CTOs tend to avoid at the beginning of an engagement. What exactly will this person own and decide? Where does strategic advisory end and executive authority begin? Who controls the codebase if the engagement ends? These questions feel premature when there is momentum and mutual goodwill — they feel urgent six months later when priorities have shifted.

Generic consulting contracts are structurally insufficient for fractional CTO work. A standard statement of work template covers deliverables and payment terms. It does not cover IP assignment for AI artifacts, the distinction between background and foreground intellectual property, the nonsolicitation of your engineering team at exit, or the knowledge handoff obligations that protect you when the engagement ends. The clauses below are the ones that matter.

Strategic advisory means the fractional CTO attends key meetings, reviews architecture decisions, and gives input on technology direction — measured in a handful of hours per week. Interim engineering leadership means running the engineering team day to day: standups, code reviews, hiring decisions, vendor negotiations. The two modes have different time requirements, different access needs, and different accountability levels. If the contract uses language like “strategic technology leadership” without specifying which mode applies, you will discover the ambiguity when a crisis requires one mode and your fractional CTO expected the other. For a clearer picture of the role itself, see what a fractional CTO actually does.

Deliverables should be defined in terms of outputs, not activities. “Attending architecture reviews” is an activity. “Delivering an architecture decision record for the data pipeline migration by the end of the engagement quarter” is a deliverable. The more concrete your deliverable list, the easier it is to measure progress and renegotiate scope when priorities change.

The hours cap clause protects both parties. Without it, there is no mechanism for the fractional CTO to push back when requests accumulate, and no mechanism for you to manage cost. A monthly cap of 20 to 40 hours is typical for a strategic advisory arrangement; interim leadership roles often require more. Specify the cap in the base agreement and the process for exceeding it — written approval, additional billing, or both.

Retainers work better when the engagement is ongoing and predictable; time and materials suits project based or irregular work. The billing model shapes the working relationship: retainers create a sense of shared commitment; time and materials can inadvertently create friction around every hour tracked.

This is not a fringe legal position — it is the baseline that courts apply when contracts are silent. Code written, architecture documents drafted, API designs produced, and system decisions made during the engagement can legally belong to the fractional CTO, not to your company, if the contract does not say otherwise.

The assignment clause must be explicit and broad. It should cover all code, documentation, architecture diagrams, technical specifications, design decisions, and any other work product created during the engagement. The phrase “all work product created in connection with the services” is the standard formulation; your lawyer can tighten it further.

AI first startups need an extended version of this clause. Standard IP assignment language was written for software. It does not contemplate fine tuned model weights, trained classifiers, evaluation datasets, optimized prompt chains, agent tool definitions, or model routing configurations. Each of these is a distinct artifact that can have independent commercial value. If the fractional CTO fine tuned a base model on your proprietary data or built a prompt library that your product depends on, the contract must specifically assign ownership of those artifacts to your company.

The background versus foreground IP distinction applies here. Background IP is what the fractional CTO brings to the engagement: prior frameworks, methodologies, and tools they built before working with you. Foreground IP is what they create during the engagement using your resources and direction. Standard practice is to assign foreground IP to the client and allow the fractional CTO to retain background IP. What matters is that the contract draws this line explicitly — and that AI specific artifacts created during the engagement are classified as foreground IP.

Code escrow is worth including for high dependency engagements. A code escrow arrangement deposits the source code, model artifacts, and key documentation with a neutral third party; if the engagement ends, you have direct access to those assets without depending on the fractional CTO's cooperation. Not every engagement needs code escrow, but high dependency AI systems — where the architecture is novel and the documentation is sparse — are strong candidates.

A six week build sprint does not justify equity. A 12 to 18 month commitment to own the technology strategy for a Series A startup does. The test is whether the fractional CTO is taking on the kind of exposure and commitment that equity is designed to compensate — not just billing hourly for skilled work.

When you include equity, match the vesting structure to your employee equity terms. That typically means a four year vest with a one year cliff — the fractional CTO receives no equity until they have completed one year of the engagement, then vests monthly or quarterly thereafter. Matching your employee schedule prevents a two tier system that creates friction inside the team. For a full breakdown of how to price the equity side of this negotiation, see how to structure the fractional CTO equity deal.

The harder negotiation points are acceleration triggers and what happens to unvested shares at exit. Single trigger acceleration means all unvested shares vest when the company is acquired, regardless of whether the fractional CTO stays on. Double trigger requires both the acquisition and a termination event. Founders generally prefer double trigger; fractional CTOs generally prefer single. The right answer depends on how essential the fractional CTO's continued work is to the acquiring company's thesis.

Avoid equity only compensation structures. A fractional CTO whose only compensation is equity is structurally misaligned with the work schedule a retainer creates. The cash retainer establishes the weekly commitment and creates accountability. The equity aligns the fractional CTO with long term outcomes. The combination works better than either alone.

A 30-day notice period is standard in consulting templates and insufficient for this role. A fractional CTO who has owned the engineering strategy for a year holds context that cannot be transferred in 30 days. Architecture decisions, vendor relationships, team dynamics, technical debt that was deliberately deferred — this knowledge takes time to surface and document. A more realistic notice period for a strategic engagement is 60 days for convenience termination, with a shorter agreed period for termination for cause.

The knowledge handoff clause should specify what the fractional CTO must deliver before the engagement officially ends. At minimum: architecture decision records for all significant technical choices made during the engagement, runbooks for recurring operational tasks, an inventory of active vendor contracts and credentials, and a documented account of any technical debt or deferred decisions and the reasoning behind them. The clause should include a timeline and a mechanism for the company to accept or reject the handoff. For context on what a fractional CTO typically owns by the time an engagement ends, see what the first 90 days of an engagement look like.

The nonsolicitation of employees provision matters most at exit. A fractional CTO who has spent months embedded in your engineering team knows who the strong performers are. A poorly structured or absent nonsolicitation clause leaves your team exposed after the engagement ends. A reasonable clause restricts the fractional CTO from directly recruiting your employees or contractors for 12 months after the engagement concludes. Broader than that becomes hard to enforce; shorter than that is often insufficient to protect the relationship the fractional CTO built while embedded.

One sided indemnification — where the fractional CTO indemnifies the company against anything and everything — is a red flag that signals a template was used without negotiation. A fair indemnification clause covers each party's obligations proportionally: the fractional CTO indemnifies against claims arising from their work product; the company indemnifies against claims arising from its business operations and the directions it gave.

The noncompete clause is often the most heavily negotiated provision. Most jurisdictions do not enforce indefinite, geographically unlimited noncompete clauses — courts treat them as unreasonable restraints on trade. A reasonable noncompete for a fractional CTO engagement limits the restriction to direct competitors in a defined market, for a period of 6 to 12 months after the engagement ends. A fractional CTO, by definition, typically serves multiple clients simultaneously — a clause that prohibits them from working in adjacent spaces is likely to be unenforceable and will create friction during negotiation.

Confidentiality clauses in AI engagements need to be more specific than “the contractor will not disclose confidential business information.” At minimum, the clause should explicitly cover: proprietary prompts and prompt chains, AI training datasets, model evaluation results, agent behavior logs, system architecture documentation, and any customer data used during the engagement. A clause that covers only “business information” leaves AI specific artifacts in ambiguity — a fractional CTO could reasonably argue that a prompt library they optimized is a professional methodology they developed, not confidential business information you own.

They were not designed for engagements where the most valuable artifacts are fine tuned model weights, optimized prompt libraries, evaluation datasets that encode your product's quality standards, or agent tool definitions that took months to get right. Every one of these artifacts should be explicitly named in the IP assignment clause and the confidentiality clause. A generic “all work product” formulation may cover them — or it may not, depending on how a court interprets the term. Naming them removes the ambiguity.

The background versus foreground distinction creates an edge case specific to AI work: what happens when the fractional CTO refines a prompt engineering methodology they developed across multiple clients? They are applying background IP — their methodology — to produce foreground IP: your specific prompt library. The contract should specify that the output belongs to you while the general methodology remains theirs. Getting this language right prevents the scenario where a fractional CTO argues that your production prompt library is a derivative of their prior work.

Data handling obligations deserve their own clause in any engagement involving customer data, regulated data, or proprietary training sets. If the fractional CTO is working with user data to evaluate model outputs, that activity may trigger GDPR Article 28 data processing obligations, HIPAA business associate requirements, or contractual obligations you have with your own customers. The contract should specify what data the fractional CTO may access, whether they may use it to train models or evaluate outputs, and what happens to any copies they create.

If you are evaluating a fractional CTO engagement, how to hire a fractional CTO covers the vetting process — the questions to ask before you sign anything and the signals that distinguish a strong candidate from an expensive mistake.