Structuring the agreement — scope, term, exchange.

What the agreement actually does

A design partner agreement is not a sales contract and it is not a vendor MSA. It is an operational instrument that codifies a structured exchange between a pre-PMF startup and an early customer, for a defined term, with a forced decision at the end. The substantive function of the document is to make four things unambiguous: what each side gives, what each side gets, when the engagement ends, and what happens at that end.

Every failure mode of the design partner motion — scope creep into custom development, founder-time saturation, false-positive product signal from over-discounted customers, the month-nine relationship that has neither converted nor terminated and consumes attention indefinitely — traces back to the absence of one of these four elements in the original document.

The exchange architecture

The exchange is the load-bearing component of the agreement. Both sides must give something material; both sides must receive something material; both sides must understand the asymmetry. A design partner who pays nothing and contributes nothing is a free user. A design partner who pays nothing and contributes substantial time is a co-development partner. The economic content of the exchange determines the category, and the category determines the product signal the engagement produces.

What the partner gives

The partner gives three things, in specified quantities:

• Structured time commitment from a decision-maker. Typically 4–8 hours per month of decision-maker access for the first 90 days, dropping to 2–4 hours per month thereafter. The hours are calendared in advance, not aspirational. The decision-maker is named in the agreement — not the analyst, not the IT contact, not whoever happens to be free. Time from anyone other than the named decision-maker is informational; time from the decision-maker is the product signal.
• Product feedback through specified channels at a specified frequency. A weekly written async update, a bi-weekly synchronous review, a shared bug-and-feature channel with response-time expectations on both sides. The vague "we'll send you our thoughts" commitment produces approximately zero structured feedback over a six-month engagement. The specified channel produces eighteen to forty-eight discrete pieces of feedback over the same period.
• Case-study and reference rights, contingent on conversion. The partner agrees in advance that if the engagement converts to a paid relationship at end-of-term, they will participate in a case study within 60 days of conversion and serve as a reference for up to six prospect calls over the subsequent twelve months. Granting these rights at signing — rather than negotiating them post-conversion — is the dominant operational pattern that produces 4–7 referenceable logos at end-of-program rather than 1–2.

What the founder gives

The founder gives four things, in specified quantities:

• Discounted or free access to the product for the term. Typically 50–90% off list, or zero-cost for the duration. The discount level is the single largest economic decision in the agreement and interacts directly with the conversion mechanic (below).
• Founder-engineering time, with a ceiling. Typically 10–15 hours per partner per month for the first 90 days, dropping to 4–8 hours thereafter. The ceiling exists for the same reason the partner's hours are specified: to prevent the engagement from silently consuming the unbounded-engineering-time resource that the startup does not have. Time above the ceiling is either explicit scope expansion (and re-priced) or declined.
• Influence on the roadmap, with founder veto. The partner gets a structured input channel into the next release's scope. They do not get unilateral feature commitments. The agreement specifies that roadmap input is solicited and considered; it does not specify that any individual request will ship. The founder veto exists because the partner does not see the other four partners' requests, the architecture constraints, or the strategic positioning calculations.
• An end-of-term option, with a specified conversion mechanic. The agreement names the price, the contract length, and the procurement mechanism for the conversion. The end-of-term price is fixed at signing, not negotiated under deal pressure six months later. This is the single most underweighted clause in design partner agreements drafted by founders without prior B2B experience.

The term length

Term length is the second load-bearing decision. The correct length is the function of the product's iteration cycle, the partner's procurement reality, and the conversion mechanic. Three durations are typical:

• 3 months — fast-validation engagement. The product is already substantively functional, the partner is in active need-state, and the engagement is testing fit rather than co-developing the product. Typical for horizontal SMB tooling where the buying decision is fast and the discovery cycle is short.
• 6 months — typical engagement. The product has a working core but meaningful gaps that the design partner motion is intended to close. The partner is operating in the product across two to three quarter-cycles, generating cumulative usage data and feedback. This is the modal duration in the YC B2B portfolio.
• 9 months — enterprise engagement. The buyer is a large organization with multi-quarter procurement, the product has meaningful integration scope, and the engagement requires sustained sponsor attention through at least one budget cycle. Rare below ACV $50K, common above ACV $150K.

The term is never indefinite. An open-ended design partner engagement is the second-most-common failure mode in this motion. The partner pays nothing or near-nothing, occupies engineering time, and has no contractual moment at which the conversion conversation must occur. The relationship becomes friction-free for the partner and structurally unprofitable for the startup, and it terminates only when one party becomes frustrated enough to force the issue under conditions that produce neither conversion nor referenceability.

The explicit end-of-term clause

The agreement specifies, in plain language, what happens at the end of the term. The two possible outcomes are: (a) the partner converts to a paid customer at the pre-specified conversion price and contract length, or (b) the engagement terminates and the partner loses product access on a defined wind-down timeline. The agreement does not contemplate an "extend the design partner relationship" outcome by default. Extensions are a renegotiation, not a continuation.

The forcing function of the end-of-term clause is the entire operational reason the design partner motion produces conversions at the 30–60% rate observed in well-run programs. The clause is what converts "we should think about pricing soon" into "we are signing or terminating by the 15th." Without it, the conversion conversation drifts past month seven, past month nine, past month twelve, and the product feedback the founder is still receiving is from a customer who has structurally never made a buying decision about the product.

Scope boundaries — the dominant failure mode

The agreement specifies that the partner receives the standard product plus configuration. Configuration means: their data, their users, their integrations to systems for which integrations already exist, their settings within the existing settings schema. Configuration does not mean: new modules, custom integrations, white-labeled UI, partner-specific data models, or any work that would not be reusable across other customers.

The per-partner deviation from this rule is the dominant scope-creep failure mode in the design partner motion. The pattern: partner expresses an integration need that is reasonable on its surface. The founder, eager to demonstrate value and capture the conversion, agrees to build it. The integration takes three to five engineering weeks. It ships, and the founder discovers that no other prospect needs it, that the partner does not value it at a price commensurate with its build cost, and that the engineering team is now committed to maintaining it indefinitely. The pattern repeats with partner #2 and partner #3, and the product ends month six with five custom integrations and zero core-product progress.

The agreement names the scope boundary explicitly. Out-of-scope requests are not declined — they are re-priced. A custom integration request becomes either a paid statement-of-work or a deferred roadmap item, and the partner is told which. The discipline of saying "that is out of scope, here is what it would cost" is the operational pattern that distinguishes the design partner motion from the unstructured early-customer-relationship motion that produces no usable product.

The pricing-discount-vs-LOI question

Two patterns are operationally viable for the economic structure of the engagement; a third is observed but problematic.

Pattern A — full-discount with conversion clause

The partner pays a token amount (often $1, often nothing) for the duration of the engagement. The agreement specifies the post-term price, contract length, and conversion mechanic. This pattern minimizes friction at signing and maximizes the number of partners willing to engage. It produces a sharper end-of-term decision because the price increase from $0 to the conversion price is psychologically large, forcing the buyer to make an active "is this worth it" judgment.

The operational cost: the partner has no skin in the game during the term, which correlates with lower feedback quality and higher no-show rates on scheduled time. The mitigation is the time-commitment specification — the partner is contractually committed to specific hours regardless of payment, and the founder enforces the commitment.

Pattern B — LOI with payable-on-conversion

The partner signs a letter of intent that commits them to a specific post-term price and contract length, conditional on the product meeting defined success criteria. The agreement carries no monetary obligation during the term but legally commits to one at end-of-term if criteria are met. This pattern produces higher feedback quality because the partner has made a future commitment that they want to be in a position to honor. It produces lower partner volume because the LOI is a procurement event that some buyers are not authorized to execute pre-purchase.

The operational cost: success criteria become a negotiation surface at end-of-term. The partner argues that criteria were not met, the founder argues that they were, and the engagement converts at a discount to the LOI price or terminates without conversion. Mitigation: success criteria are written in measurable, partner-verified language at signing, not in subjective language reserved for later interpretation.

The pattern to avoid — moderate-discount without conversion mechanic

The partner pays 30–50% off list for the term, with no specified conversion price or mechanic. This produces the worst of both patterns: friction at signing high enough to reduce volume, no forced end-of-term decision, and a renewal conversation at the same discount that the partner has now anchored on. The partner stays at the discount indefinitely; the founder's ARR per customer is structurally suppressed; the design partner program has degenerated into a permanent discount tier.

Reference and case-study rights

The agreement grants reference and case-study rights at signing, with the explicit understanding that case-study production happens post-conversion. The rights granted are: use of the partner's name and logo on the website and in materials, use of a quote attributed to the named decision-maker, production of a long-form case study within 60 days of conversion, and reference participation for up to six prospect calls over the twelve months following conversion.

Granting these rights at signing rather than negotiating them post-conversion produces a roughly 3x difference in the rate at which design partners become referenceable logos. The reason is structural: post-conversion, the partner has no incentive to incur the time cost of case-study production or reference calls; pre-conversion, the rights are a low-cost concession in exchange for substantial product access. The case study still requires the post-conversion conversation to produce — but the conversation is about timing and content, not about whether it happens at all.

IP and data ownership

The agreement names IP and data ownership explicitly. The founder retains all IP in the product, including any IP arising from work done during the engagement. The founder retains aggregated and anonymized usage data from the partner's interaction with the product. The partner retains all of their own data — customer records, transactional data, any content uploaded into the product — and retains the right to export it at termination. The partner retains any partner-specific configurations they have authored within the product's configuration surface.

Ambiguity in IP allocation is a long-tail failure mode that surfaces months or years later, typically at the partner's acquisition or at the founder's fundraise. The four-sentence clause that allocates IP unambiguously at signing prevents the six-week diligence delay that the absence of that clause produces.

Termination clauses

Three termination rights are typical:

• Mutual termination with 30-day notice. Either party may terminate the engagement for any reason with 30 days written notice. This is the standard escape valve and is almost never exercised in well-functioning engagements.
• Founder termination right for non-engagement. The founder may terminate immediately if the partner fails to meet the specified time commitment for two consecutive monthly periods. This clause exists to terminate dead engagements — the partner that signed, never showed up, and is now consuming nothing but a slot in the program count. Without the clause, the engagement runs to term and the founder has spent six months with one less active partner than the program count implies.
• Partner termination right for product-readiness failure. The partner may terminate immediately if the product fails to meet baseline functionality defined in the agreement — uptime below a specified threshold, security incident, fundamental capability gap that makes the product unusable for the partner's specified use case. This clause is the partner's protection against being held hostage to a product that has materially failed to ship; it is almost never exercised but is meaningful at signing.

The legal-document template structure

The design partner agreement is a 4–6 page document, not a 30-page contract. The document is signed by both parties, dated, and stored in the founder's deal-management system alongside the engagement plan. Legal review is performed on the first instance — typically a 2–4 hour engagement with outside counsel at $400–800/hr, producing a reusable template — and the template is reused thereafter with only the per-partner economic terms, named decision-maker, and term dates modified.

The instinct to produce a one-page handshake memo is reasonable but produces too little operational specificity. The instinct to produce a vendor MSA is reasonable but produces too much friction at signing and signals the wrong relationship type. The 4–6 page template, with the exchange architecture, term, scope boundaries, conversion mechanic, IP allocation, and termination clauses all named explicitly, is the dominant pattern that survives a six-month engagement without being renegotiated mid-stream.

The renewal-vs-convert decision at end-of-term

The agreement specifies that the end-of-term moment produces one of two outcomes: conversion at the named price and length, or termination on the named wind-down. Renewal of the design partner relationship at the same terms is not a default option. If both parties wish to extend, they execute a new agreement with new terms — typically a partially-paid extension at a smaller discount, with a new end-of-term date and a new conversion mechanic.

The mechanics of the conversion conversation, the price negotiation, the contract-length question, and the empirical conversion rates by engagement quality are the substance of Chapter 5. The agreement structure described here is the precondition that makes those mechanics possible. Without the explicit end-of-term clause and the pre-specified conversion price, the conversation in month six is a sales negotiation against a customer who has been receiving product access at a 90% discount and has no anchor price other than that discount.

Common operator failures observed in production

• No agreement at all. The engagement is conducted on a handshake and a shared notion of mutual interest. Predictable outcomes: scope creep, founder-time saturation, ambiguous termination, no conversion mechanic, no reference rights, IP ambiguity. The most common failure mode in YC B2B teams under six months from incorporation.
• Indefinite term. The agreement exists but contains no end date or end-of-term mechanic. The engagement runs until one party exits it under duress. The conversion conversation never occurs structurally; the partner becomes a permanent discounted customer or a permanent unpaid user.
• No scope boundary. The agreement does not specify that the partner receives standard product plus configuration. The founder agrees to per-partner custom development, the engineering roadmap collapses into custom-integration backlog, and the core product fails to advance.
• No exchange clarity. The agreement does not specify what either party gives in measurable terms. The partner shows up irregularly, feedback is sporadic, the founder's time allocation is unbounded. The engagement produces neither product signal nor a paying customer.
• IP ambiguity. The agreement is silent on IP and data ownership. The question surfaces at the partner's acquisition or at the founder's fundraise diligence. Resolution requires retroactive negotiation under deal pressure and is the operational pattern that produces 4–6 week diligence delays.
• No termination clause. The agreement has no defined termination mechanism. The engagement that should have ended at month three for non-engagement runs to month six and consumes a partner slot that could have been recruited into. The engagement that should have terminated at month four for product-readiness failure persists, generates a hostile partner, and produces a negative reference in the segment.

Pre-signing checklist

• Named decision-maker on the partner side, with time commitment specified in hours per month and a calendared kickoff
• Specified feedback channels and frequency, with response-time expectations on both sides
• Reference and case-study rights granted at signing, contingent on conversion
• Discount or free-access terms named explicitly, with the post-term conversion price and contract length pre-specified
• Founder-engineering-time ceiling named in hours per month, with the mechanism for out-of-scope requests defined
• Scope boundary named: standard product plus configuration, custom development re-priced or deferred
• Term length named, with the specific end date and the end-of-term decision mechanic
• IP allocation and data ownership named in plain language
• Three termination rights named: mutual 30-day, founder for non-engagement, partner for product-readiness failure
• Document length 4–6 pages, signed by both parties, stored alongside the engagement plan
• For the first instance: legal review with outside counsel producing a reusable template; subsequent instances use the template with per-partner economic terms only

Where the agreement fits

The agreement is the bridge between recruitment (Chapter 2) and the operational program (Chapter 4). Recruitment produces signed partners; the agreement produces the structure that makes the next six months operationally tractable; the program is the weekly cadence that runs inside that structure. Conversion (Chapter 5) is the end-of-term moment that the agreement makes inevitable, at terms the agreement has pre-named.

The substantive function of the document is to remove decisions from the high-pressure moments where they would otherwise occur. The conversion price is named at signing — when the founder has perspective and the partner has interest — not at month six under deal pressure. The scope boundary is named at signing, not in the middle of a feature negotiation where the founder is incentivized to over-commit. The termination mechanism is named at signing, not in the middle of an engagement that has gone sideways. The agreement is the artifact that converts the design partner motion from a relationship-management exercise into an operational system that produces predictable outcomes at the empirically observed conversion rates.