How to structure a corporate-startup co-development agreement (without killing the startup)

The decision that comes before the agreement

Most co-development negotiations start in the wrong place. Both legal teams open their template documents and begin exchanging redlines before the people who will actually do the work have agreed on the four questions that determine whether the relationship will succeed or fail. By the time those questions surface, positions are entrenched and the negotiation has become adversarial.

The four decisions are not legal details. They are business decisions that shape everything else. They need to be made by the business leads, in conversation, before the lawyers are involved. Once they are agreed, the legal drafting is relatively straightforward. Without agreement on them, no amount of legal precision will save the relationship.

Decision 1: who owns the IP that gets created?

This is the question most co-developments leave implicit and most disputes are eventually about. The corporate assumes it owns everything built with its data, its domain expertise and on its budget. The startup assumes it retains the core technology because its engineers wrote it and it forms the foundation of their product. Both assumptions have some legal basis and neither is completely right. The result is a mess that surfaces at the worst possible moment — usually when the relationship is already under strain.

The workable options, in order of how often they actually work:

• Startup owns the output, corporate gets a defined license. The startup retains its IP, including improvements made during the project. The corporate receives a license that specifies what it can do with the output (use internally, commercialise in defined markets, sublicense to subsidiaries or not). This is the most founder-friendly structure and the cleanest to administer.
• Corporate owns the project output, startup retains the underlying technology. What the corporate owns is the specific configuration, integration and any bespoke features built for them. The startup retains the platform, the algorithms, the proprietary methods. Both parties get a license to what the other owns for the purposes of the project. This is workable but requires very precise definition of what counts as "underlying technology."
• Purpose-built vehicle holds the IP. A new entity is created to hold the jointly developed IP, in which both parties hold equity. This is the most defensible structure legally, the most complex to set up, and usually only makes sense when the co-development output is significant enough to become a standalone business.
• Joint ownership. Sounds equitable. Is almost always the worst option in practice. Joint owners can typically each use the IP independently but neither can license it to a third party or sue for infringement without the other's consent. Two companies making those decisions together, with potentially divergent commercial interests, is a recipe for paralysis.

Decision 2: is there equity involved?

Some co-developments are purely contractual: the startup delivers a service or a product, the corporate pays for it, the relationship is a commercial one. Others involve the corporate taking a stake in the startup, or both parties co-founding a new entity. This decision changes the entire nature of the relationship and needs to be explicit from the first conversation.

Equity involvement is not automatically better for either party. For the startup, it can signal commitment and lock in a strategic partner. It can also introduce a shareholder with veto rights and different incentives from the founding team. For the corporate, equity provides upside if the startup succeeds. It also creates obligations, potential conflicts of interest, and governance complexity that most corporate legal and finance teams are not set up to manage efficiently.

If equity is part of the conversation, the valuation, the instrument (simple agreement for future equity, convertible note, direct share purchase) and the governance rights that come with it need to be resolved before the co-development agreement is drafted. They are too consequential to treat as a side letter.

Decision 3: what is the exclusivity scope?

Corporates almost always ask for exclusivity. The ask is legitimate: they are investing budget, opening internal access and taking a reputational risk on an early-stage company. They want to know that a competitor will not get the same advantage six months later.

The problem is that "exclusivity" can mean very different things, and the version that protects the corporate's legitimate interest is almost never the version that gets asked for first. Blanket exclusivity in an industry vertical — "you cannot work with any other financial services company" — can lock a B2B startup out of its entire target market. The startup signs because it needs the deal. It discovers the constraint when it tries to close its next customer and cannot.

This section of the agreement needs to specify four dimensions of exclusivity precisely: what is exclusive (the output, the technology, a market application), where it applies (geographic scope), for how long, and what triggers the exclusivity to expire early (revenue milestones, deployment targets, or simply the passage of time).

Decision 4: what are the exit conditions?

The exit conditions are as important as the entry conditions and receive a fraction of the attention. Every co-development ends in one of four ways: it succeeds and both parties continue; it succeeds and the corporate acquires the startup; one party walks away before completion; or the project simply runs out of momentum and quietly dies. The agreement needs to govern all four outcomes explicitly.

The questions that need answers: what happens to the jointly developed IP if the corporate terminates early? Does the startup get to keep what was built on its own technology? What happens if the startup is acquired by a competitor of the corporate during the project? What are the payment obligations if one party exits before milestones are reached? Is there a right of first refusal on acquisition?

These are not edge cases. In my experience across dozens of corporate-startup collaborations, the relationships that end badly almost always end badly precisely at one of these transition points, in the absence of a pre-agreed framework. For more on the patterns that cause corporate-startup collaborations to fail, the practical framework for corporate-startup collaboration covers the structural dynamics in detail.

What the agreement actually needs to cover

Once the four business decisions are resolved, the legal drafting can begin. The common mistake is using a standard NDA plus services agreement template and patching it for the co-development context. Co-development is a distinct relationship type that the standard templates are not designed for.

The essential clauses beyond IP and exclusivity:

Work plan and milestone governance. Not just what will be delivered, but who approves it, in what timeframe, with what process when there is disagreement. The more precise this section is, the fewer disputes arise. Vague deliverables produce vague conversations about whether they have been met.

Data sharing and data ownership. When the corporate provides proprietary data (customer records, operational data, market intelligence) for the startup to use in development or model training, the agreement needs to specify what the startup can do with that data, whether it can be used to improve the startup's general product, whether it can be retained after the project ends, and what happens to any derivative insights or models. This is increasingly regulated territory in Europe under GDPR and the EU AI Act.

Publication rights. The startup may want to publish research outputs, case studies or technical papers. The corporate almost never wants this, at least not without review. A publication rights clause that requires corporate sign-off before any external disclosure, with a defined review period and a deemed-approval mechanism if no response is received, balances both interests.

Sublicensing rights. Can the corporate give the jointly developed output to its subsidiaries? To its clients? To third-party integrators? This matters enormously for the startup's economics and competitive position, and it is frequently left ambiguous in first drafts.

Change of control. Addressed above as an exit condition, but worth specifying in the agreement itself: what constitutes a change of control, what rights it triggers, and for whom.

Payment structure. Milestone-based payments align incentives better than time-based retainers. The corporate pays when defined outputs are delivered. The startup has a clear and objective target. Disputes about whether work has been done become much rarer when the definition of "done" is in the contract rather than in someone's inbox.

Operational governance: the part most agreements skip

A co-development agreement is not just a legal document. It is an operating framework for two organisations that work differently to collaborate without one absorbing the other. The legal terms govern what happens when things go wrong. The governance model determines whether things go right.

The governance model needs to answer four questions that most agreements do not address:

Who is the single decision-maker on each side? Not a committee. Not "the relevant team." A named individual with the authority to approve scope changes, resolve disputes and make binding commitments on behalf of their organisation. Without this, every decision escalates. Every escalation takes time the startup does not have.

What is the cadence and format of progress reviews? Weekly standups for operational matters, monthly steering reviews for strategic alignment. Both with defined attendees, defined outputs and defined decision rights. If the corporate stakeholder changes six months in (it will), the new person steps into a structured relationship, not an undocumented one.

What is the process for scope changes? They will happen. The corporate will want to add something. The startup will discover that the original spec was wrong. The process for handling this — proposal, review period, approval threshold, budget impact — needs to exist before the first scope change request arrives.

How are disputes escalated before they become crises? A tiered escalation path: operational lead to business lead to executive sponsor. A defined timeline at each tier. This is not a sign of distrust. It is a sign that both parties are serious about making the relationship work.

Exclusivity: the clause that ends startups

This deserves a section of its own because the consequences are severe enough that one badly drafted clause can make a startup unfundable, unsaleable and operationally constrained for years.

The problem is not exclusivity as a concept. A corporate investing significant budget and opening internal access has a legitimate interest in not immediately arming a competitor. The problem is that corporate legal teams default to the broadest possible exclusivity language, and startup founders sign it because they need the deal and do not have the leverage to push back in the moment. They discover the constraint when they try to close their next customer and cannot, or when they go to raise their Series A and a VC asks about exclusivity commitments.

Before accepting any exclusivity clause, a startup needs to be clear on four alternatives that protect the corporate's legitimate interest without restricting the startup's ability to build a business:

• Time-limited exclusivity. Exclusive for a defined period (12 to 18 months is reasonable for most co-developments), after which the startup is free to work with others in the same space. The corporate gets a head start. The startup does not sign away its market.
• Geographic exclusivity. The corporate gets exclusivity in the markets where it actually operates. If the corporate is a European bank, exclusivity in European banking is relevant. Exclusivity in US banking is not, and the startup should not give it away.
• Use-case exclusivity. Exclusive for this specific application (fraud detection in retail banking, for example), not for the underlying technology or for the entire financial services vertical. The startup retains the ability to build other applications on the same technical foundation.
• Right of first refusal. Not exclusivity at all. The corporate gets the right to match any offer the startup receives from a competitor before the startup signs with them. This is meaningfully weaker than exclusivity but meaningfully stronger than nothing, and it is a reasonable middle ground when positions are far apart.

None of these alternatives are standard. All of them are negotiable. The startup's job is to understand what exclusivity it is actually giving before signing, and to know which dimensions it can afford to concede and which it cannot.

The EU funding dimension

This is specific to the European context and consistently underused. A co-development between a corporate and a startup, if structured from the beginning with the right consortium and the right project scope, can qualify for Horizon Europe funding. This changes the economics for both parties in ways that are not immediately obvious.

A consortium of corporate plus startup plus at least one research or academic organisation from different EU Member States can apply to relevant Horizon Europe calls under Pillar 2 or through specific partnerships. If successful, each consortium partner receives their share of the budget directly from the European Commission as a grant — not as a loan, not as equity, not as revenue from the other consortium partners. The corporate's contribution to the startup's development costs is effectively replaced, in whole or in part, by EU grant funding. The startup's development costs are covered without additional dilution.

The IP ownership question, which is the hardest to resolve in a commercial co-development, is partly governed by Horizon Europe's model grant agreement, which provides a battle-tested framework for background IP, foreground IP, access rights and exploitation obligations. Many startups and corporates find it easier to agree on IP in the Horizon Europe context than in a purely commercial one, precisely because the framework exists and is not invented for the occasion.

The constraint: the project must be designed with the EU funding application in mind from the start, not retrofitted afterward. The scope, the consortium composition, the innovation ambition and the expected impact all need to meet the criteria of the specific call. A commercial co-development that is already underway cannot be repackaged as a Horizon Europe project. But a co-development that has not yet started can be designed to qualify, and the difference in funding outcomes can be significant. For a comparison of the main EU instruments and how to choose between them, see EIC Accelerator vs Horizon Europe: which one is right for your startup. For support structuring your co-development project to qualify from the start, see the EU funding consultancy at Ipernovation.

From the field: how exclusivity scope actually breaks

A pattern I encounter repeatedly in corporate-startup co-developments: the startup and corporate agree on "exclusivity in our sector" during negotiation. Both parties believe they are aligned. What the startup understood was exclusivity on the specific output built for this project. What the corporate's legal team drafted covered the entire vertical.

The startup signs because it needs the deal. Twelve months later, it tries to close a second customer in the same industry. The corporate invokes the clause. The startup is either in breach or loses the deal. By that point there is usually enough relationship momentum to manage the dispute -- but the next investor who runs due diligence on the exclusivity commitment will flag it, and the startup will spend three months negotiating a release they should never have given in the first place.

The fix is not refusing exclusivity. It is specifying what "sector" means in the agreement itself: a named list of companies, a geographic market, a specific product category, or a defined use case. Vague terms are not a sign of trust. They are a deferred negotiation at the worst possible moment.