A joint product with an engineering partner: who owns what

Joint product deals rarely die on the economics. They die on ownership, and they die late. Two firms spend a quarter agreeing that one has the market and the other has the engineering, build a working thing, take it to a first customer, and then discover that nobody wrote down who owns the code, whether the partner can sell a similar system next year, whose name appears on the support agreement, or what happens to the product if the partnership ends. At that point the answers cost more than the build did, because they are being negotiated between two parties who each have a customer expecting delivery.

None of this is hard. It is a set of about ten decisions, all of which can be made in a week if someone puts them on one page and forces the conversation. This is that page, written for the executive who has to make the deal work rather than for the lawyer who will paper it. The order matters: the questions below are arranged so that the answer to each one narrows the next.

Decide what kind of thing you are building

Almost every later argument traces back to this question being left vague. There are four common structures and they have different answers to everything else.

A build for hire with a product wrapper. One firm pays, owns the result outright, and the other firm builds it. Simple, clean, and the right structure far more often than it gets used, because "partnership" sounds better in a board update than "we hired engineers."

A joint product with shared economics. Both firms contribute something neither can buy easily, both are exposed to the outcome, and revenue is shared. This is the structure people mean when they say joint product, and it is the one that requires the real work below.

A licensed platform with a customer-specific layer. One firm owns a platform and licenses it; the other builds and owns the layer that faces a particular market. Ownership is clean at the boundary, and the whole deal is about where the boundary sits.

A white-label arrangement. One firm builds, the other sells under its own brand, and the builder is invisible. Economically a supply agreement, and it should be papered as one, with the interesting clauses being exclusivity and support rather than ownership.

Naming the structure in the first meeting saves a month. Two parties who each privately believe a different one of these is happening will agree on every term and disagree on every consequence.

Background rights: the schedule that prevents the worst argument

Every engineering firm arrives with existing material. Deployment tooling, data-processing components, evaluation suites, connectors, internal libraries. Every product company arrives with its own: models, datasets, taxonomies, brand, customer relationships, an existing application the new thing plugs into.

The single most useful document in a co-development deal is a schedule listing that material by name, dated at signature, and stating that it remains the property of whoever brought it. It takes an afternoon. Without it, every future dispute about ownership becomes an archaeological argument about when a component was first written, and archaeology is expensive and inconclusive.

Pair the schedule with a license in the direction the product needs. If the joint product depends on one party's background material, the other party needs a license to use it inside the product, for the life of the product, on terms that survive termination. A license that ends when the partnership ends means the product ends too, which converts a commercial disagreement into a customer-facing outage.

Foreground rights: three workable patterns

For what is created during the work, three patterns cover almost every real deal.

One owner, one broad license. One party owns everything created, and the other takes a perpetual, irrevocable license in a defined field of use. Clean, easy to administer, and it works when one party is clearly the product owner and the other is clearly the builder. The negotiation is entirely about the field of use.

Split by layer. Ownership follows the architecture: the platform components belong to the firm that will maintain them across many customers, the market-specific application belongs to the firm whose market it is. This is usually the best answer for a genuine joint product, because it matches ownership to who has the incentive to keep each part alive. It requires the architecture to have a real boundary, which is an engineering decision made early and deliberately.

Joint ownership. Both parties own everything together. It sounds fair and it is the pattern that creates the most trouble, because joint owners of a copyright can generally each exploit the work independently and the accounting between them is a matter of law and agreement rather than something obvious. If joint ownership is chosen, spell out consent rights, accounting duties and what either party may do unilaterally. Most deals that start here end up at one of the first two patterns after a lawyer explains the consequences.

One drafting point applies whichever pattern is chosen. For commissioned software, a present written assignment of copyright is what transfers ownership. A work-made-for-hire recital alone is not enough, because under 17 U.S.C. § 101 a commissioned work qualifies as a work made for hire only where there is a written agreement and the work falls within one of nine enumerated categories, and software is not among them. Agreements that rely on the recital and skip the assignment leave a party holding an implied license where it believed it held title.

Exclusivity: narrow it in three dimensions

Exclusivity is where deals get emotional, because each side hears the request as a statement about trust. It is not. It is a question about which competing activity would actually damage the other party, and the answer is almost always narrower than the first draft.

Cut exclusivity along three axes. By field: exclusive for insurance claims processing, not for all software. By geography or market segment: exclusive for the United States federal market, not globally. By time: two years from first customer availability, then converting to a non-exclusive arrangement or renewing against a performance threshold.

The performance threshold is the term that makes exclusivity acceptable to the party granting it. Exclusivity in exchange for nothing is a option written for free. Exclusivity that continues only while the other party sells a stated amount is a commercial arrangement, and it also removes the most common late-stage failure, where one party holds an exclusive right in a market it has stopped working.

Say plainly what each side may still do. An engineering firm will keep building similar systems for other clients; that is how it stays good at the thing you hired it for. A product firm will keep selling adjacent products. Write both permissions down rather than leaving them to be inferred, and the residual-knowledge clause becomes a formality instead of a fight: people carry general skills and know-how in their heads and may use them, while specific confidential material and specific code do not travel.

Data rights, stated separately from IP

Data is where modern co-development deals go wrong, because the intellectual property clause was drafted for software and quietly assumed to cover everything else. It does not, and the questions are different.

Five decisions belong in their own section. Who owns raw customer data, which is almost always the customer and should be said explicitly. Who owns derived data such as aggregate statistics, embeddings, or a cleaned and normalized version of a messy source. Whether either party may use customer data to train or evaluate a model, and if so whether that use survives the customer relationship. Who owns the trained model weights and the evaluation sets. And what is retained, for how long, in logs and in traces, which matters more than it sounds because inference logs frequently contain the customer's most sensitive content.

The technical reality that should shape these clauses: in a system built on machine learning, the model weights are often less valuable than the evaluation set and the labeled data behind it. Anyone can fine-tune. Almost nobody has a curated set of hard cases with correct answers attached, and that asset is what makes the next version better. If you are negotiating who owns the model and not who owns the evaluation data, you are negotiating the wrong asset.

Brand, customer contract and the support obligation

These three travel together, because whoever signs the customer is the party the customer will call at two in the morning.

Decide who contracts with the end customer. If one party does, it carries the service commitments, the liability and the collection risk, and the other party's obligations to it should be written as a back-to-back agreement whose terms are at least as strong as the customer-facing ones. A support commitment to a customer that is not matched by an equivalent commitment from the party who can actually fix the software is an unfunded promise.

Then decide the support model concretely: which party takes first contact, what the escalation path is, response and resolution targets by severity, who runs the production environment, who holds the credentials, and who may deploy a fix. Write the on-call rotation into the agreement if both parties are in it. And name the branding posture, including whether the engineering party is identified at all, and whether it may reference the product in its own materials after launch.

Revenue share: define the base before the percentage

The percentage is the easy part. The base is where the value sits, and it is routinely left to be worked out later, which means it is worked out in a dispute.

Say which revenue counts: only the joint product, or also services sold around it, or also the existing product the joint one is bundled with. Say whether the share is on gross revenue, on revenue net of stated costs, or on collected cash. Say what happens to a discount, and to a multi-product deal where a customer negotiates one number for several things: the allocation rule has to be written, because otherwise the party doing the selling allocates in its own favor without meaning to. Say who pays third-party costs such as cloud infrastructure and model inference, which in a machine-learning product can be a large and variable line. And give the other party an audit right with a stated frequency and a cost-shifting rule if a material error is found.

A minimum payment or a floor is worth considering when one party is contributing engineering at risk. It converts an option into a commitment, and it disciplines the sales side of the partnership in the same way an exclusivity threshold does.

Keep the engineering moving while the paper catches up

The practical problem with everything above is that it takes six to ten weeks and the market does not wait. The answer is not to skip it. The answer is to sequence so that the early work is safe to do under a short agreement and creates nothing that would be painful to unwind.

A short letter agreement can cover the first four to six weeks: confidentiality, a statement that each party retains what it brought, a default that anything created in this period is assigned to one named party, and an agreed cap on spend. Under it, do the work that is genuinely reusable no matter which structure wins: build the integration and data-access layer, establish the evaluation set and the measurement suite, stand up environments and the deployment pipeline, and produce a technical feasibility finding in writing. None of that is wasted if the deal changes shape, and all of it makes the eventual scope more accurate.

What not to do in that window: build the customer-facing product, sign a customer, or make the architectural decisions that determine the ownership boundary. Those are the decisions the agreement is supposed to make, and making them in engineering first means the paper is documenting a fait accompli rather than governing a choice.

How we work in a co-development deal

Precision Federal builds products with firms that have a market and need engineering, and our posture on all of the above is deliberately simple, because a partner arguing about ownership is a partner slowing the product down.

We are comfortable with the client owning everything created in the work, assigned in writing at the outset. Our existing tooling is listed by name in a background schedule at signature and licensed to the client perpetually inside the product, so nothing we brought can ever hold the product hostage. Where a genuine joint product justifies splitting ownership by layer, we will do that, and we will design a real architectural boundary so the split means something in the code rather than only in the contract.

Commercially, we work as fixed-price milestones with acceptance criteria written as tests, or as a committed team at a stated monthly cost against a quarterly roadmap. Both shapes are compatible with a revenue share layered on top when a partner wants engineering exposed to the outcome. On brand, we default to invisible: the client's customers are the client's, and we appear only where the client wants us to.

In the first weeks a partner gets a written architecture with the ownership boundary drawn explicitly, environments and pipeline running, the evaluation and measurement approach agreed, and a milestone plan with prices attached. We also build and deploy inside federal agencies, which matters for any joint product aimed at government buyers, because the authorization, control evidence, controlled-unclassified-information handling and accessibility work is what decides whether a product can be sold there at all. The first step is one email with a one-page brief, and we return a scoped, priced statement of work.

Termination: write the ending at the beginning

The termination section is read once, years later, by people who are angry. Write it for them.

• Licenses that survive. Any license the product depends on continues for the life of deployed customer instances, at minimum. Otherwise termination breaks live customers, and neither party can afford that outcome.
• Customer continuity. Who keeps the customer relationships, whether the other party may contact them, and a transition period long enough for a real migration rather than a notice period long enough for a lawsuit.
• A technical exit that is a deliverable. Source, build pipeline, infrastructure as code, environment configuration, credential rotation, runbooks, and a rehearsed handover where the receiving team deploys while the other watches.
• Data return and destruction. What is returned, what is destroyed, on what schedule, with a certificate. Include model artifacts and inference logs, which the clause usually forgets.
• Wind-down of revenue share. A tail on existing customers, and a clean end for new ones, with the cut-off defined by contract signature date rather than by delivery date.

Bottom line

A co-built product is ten decisions, not a negotiation. Name the structure in the first meeting. Schedule the background material by name and license it in the direction the product needs. Choose one of three foreground patterns and use a present written assignment rather than a work-for-hire recital. Narrow exclusivity by field, market and time, and attach a performance threshold. Treat data, models and evaluation sets in their own section, and notice that the evaluation set is usually the asset worth arguing about. Tie brand, customer contract and support together, back to back. Define the revenue base before the percentage. Then write the ending at the beginning, and run the first six weeks under a short letter agreement so the engineering never waits on the paper.

Frequently asked questions