Who Warrants What

This chapter sets out an illustrative contract structure for inherited prototype code. The clause summaries, durations and allocations below are proposals for discussion with counsel, not quotations from a verified Sliday agreement or a statement of our current terms.

Start with the old assumption: a studio writes the delivered code and assigns it to the client. A simple warranty of original work can appear to fit that arrangement. It becomes harder to describe the work that way when a founder brings a codebase the studio did not write.

None of that is true any more, and the contract is where the untruth shows up first. A founder can arrive with substantial parts of what they believe is a production codebase. They have used Cursor, Claude Code, Bolt, v0, a combination. They do not always know, when asked, which lines are theirs in the keystroke sense and which were suggested by a model they accepted. And this is before the studio has written a line.

Three subjects carry the weight in this proposed structure: IP assignment, an audit period and provenance disclosure. Four further subjects belong in the agreement too. The three that follow are the ones I would discuss with a founder at the first call.

IP assignment

In the old agreement, the studio assigned all intellectual property in the delivered code to the client on final payment. That describes the old assumption.

The clause is nonsense in an engagement where the founder has built the first half of the production codebase themselves. The studio cannot assign what it does not own. The founder cannot receive, on final payment, something that was already theirs five months earlier. And neither party can pretend that the cleaned-and-hardened repository we hand back at the end is either purely the studio’s work or purely the founder’s.

The proposed clause has three parts. The founder warrants ownership of the prototype code they bring in, to the extent ownership can be warranted over a probabilistic artefact (the warranty is qualified on that point, explicitly). The studio assigns IP in the work it produces, on the studio’s side of a commit boundary that we agree in writing during the audit. A joint clause covers the seams: the parts of the production codebase where the founder’s original lines and our new lines are intertwined beyond clean separation, and where neither a unilateral assignment nor a unilateral retention describes the commercial reality. The third part describes a shared object and needs particular attention from both parties’ counsel. A clause that describes a shared object is worth more than two clauses that pretend the object is not shared.

Audit period

The audit-period clause defines the work before a final price or scope. In this example, the studio spends five to fifteen working days inside the repository with the founder’s permission. That duration is an illustrative allowance, not a default rate-card commitment.

We read the code. We run the tests, if there are tests. We map the dependencies. We identify the parts that are load-bearing, the parts that are ornamental and the parts that will not survive contact with a production user. The founder sits in the audit with us (not every hour, but at the opening scoping session and the closing walk-through) and leaves with a written report that names what is keepable, what is not and what it would cost to rebuild each section.

The agreement should say whether the founder can take the report to another studio if the engagement does not proceed. It should also name the audit fee, cap and deliverables before the work begins. A paid audit and a short introductory triage are different services; the parties need to state which one they are buying.

The hardening-warranty clause names the window in which the studio stands behind the hardening without further billing: the commercial-discipline clause that makes the rest of the agreement signable. For this example, use ninety days from the handover commit. The parties must agree the actual period and exceptions. Defects found inside the window are fixed on us. Defects found outside the window are chargeable, unless they trace to a named section in the audit report we missed. The founder reads this clause more carefully than any other, and they are right to.

Provenance disclosure

The third clause is the one we are still discovering the shape of as we write it.

The founder arrives with code. Some of the code is theirs in the keystroke sense. Some was suggested by a model they accepted without reading closely. Some came from a paired session with a collaborator they are no longer in touch with. We arrive with our own studio practice, which now uses Claude Code, Cursor and a rotating set of lesser tools in the course of finishing what the founder hands us. The studio can take responsibility for its review and delivery without claiming to have typed all the code.

The provenance disclosure clause names all of it. It lists the tools we use (by name, by version where version is meaningful) and the categories of task we use them for. It lists the review process our engineers apply before a line reaches the main branch, in enough detail that a third reader (an investor, a board member, an acquirer) can tell whether the process is theatre or discipline. It names what the founder has disclosed to us about their own prototype practice, and it names what they have not been able to disclose because the tool did not keep a log.

A founder may worry about how a disclosure reads to an investor or acquirer. The parties should discuss that concern rather than remove the account of how the codebase was built. A disclosure they can show is worth more than a warranty they cannot defend.

The clause is also the one that quietly cascades into a chapter the book will reach for later, which is how the founder reads the disclosure when it is turned on themselves: the moment the studio names, in writing, the parts of the founder’s own work the studio cannot warrant. That is the material The Founder’s View takes up from the founder’s side of the glass. The legal object is this chapter’s concern; the emotional object is that chapter’s.

Further clauses, at a glance

The next four clauses matter. They do not carry the weight of the three above, and we treat them briefly rather than as full sections because, in our experience, founders do not argue about these four at the first call. They agree, or they disagree, quickly, and the studio’s job is to have written the answer down.

Security warranty. An old-style clause might read: studio warrants code is secure to prevailing professional standards. The proposed version reads: the studio warrants its own review process against a named checklist; flaws present in prototype code the founder brought in are the founder’s warranty; flaws in the seam are allocated case by case. The change is necessary because neither party can warrant the absolute security of code neither party fully wrote. The old clause sat cleanly on the assumption the studio wrote everything. The new version carves the warranty along the commit boundary from the audit report.

Secrets handling. An old-style clause might contain a single undertaking: the studio would not commit credentials. The proposed version keeps that undertaking and adds a mandatory scan of the inherited prototype repository’s git history for secrets, run during the audit, with a remediation line item. Prototype repositories routinely carry committed secrets in their history. Rotating them is now a named, invoiceable task rather than an assumed hygiene measure.

GPL contamination risk. An agreement may be silent on this. The proposed version warrants that the studio has run licence-scanning software against the delivered codebase and has not knowingly incorporated GPL code into a proprietary deliverable. It explicitly does not warrant the absence of training-data-derived licence risk, because the parties may not know which source material contributed to an output. A scan of delivered code does not establish the provenance of a model’s training corpus. The parties need counsel to assess what assurance they can give.

Studio-side AI use disclosure. An agreement may be silent on this. The proposed version has the studio disclose the models it uses, the categories of task and the review process. This disclosure supplements the provenance-disclosure clause above. An investor or acquirer asking “how was this built?” in 2026 expects a named answer; a studio that has nothing to disclose has either never looked or is hiding the answer.

Each subject needs negotiation and legal review in the parties’ jurisdiction. These summaries explain the questions to ask; they are not ready-to-sign legal templates.

The purpose of the agreement is to let both parties name their work, responsibilities and limits. It should name what the studio warrants and what it will not build. A clean document describing the wrong reality gives the parties less help than one that addresses the work in front of them.

Every clause in the old contract assumed the studio wrote everything; that assumption is now wrong by half.