Skin in the game: how an AI build partner earns the next commitment

A build partner has skin in the game when part of its own contribution to a proof is at risk: senior time, product work or development that it carries itself until the evidence shows whether a next commitment is justified. At Nova that contribution is capped and agreed before the proof starts, the proof runs in three phases across three workstreams, and the follow-on model is decided in the last phase. This article explains that mechanism from the builder's side.

The investor's side of the question, whether private equity needs a different kind of operating capacity for AI, is set out in the case for a new type of AI operating partner, published by ScopeRight, an independent assessment and scoping practice. Here we stay with a narrower subject: what a technical co-building partner in private equity actually commits to an AI build, and what it has to earn.

What does skin in the game mean for a build partner?

Skin in the game, for a build partner, means that a defined share of the partner's work on a proof is carried at the partner's own risk. The share is capped, agreed before the proof starts, and tied to a decision point at which both sides choose to stop, adjust or scale.

It is not another word for equity. Equity is not automatically part of every project, and a regular, paid build is always an option.

Why should a build partner put part of its contribution at risk?

A fee-only builder is paid for effort. Whether users adopt the workflow, whether the business case holds and whether the software can be used a second time are someone else's concern. That is reasonable when scope and value are already clear. It is weaker when the value is plausible but unproven, which is where most AI value-creation theses begin.

Putting part of our contribution at risk changes three things.

• It ties the builder to adoption, not to delivery. Our contribution only makes sense if real users keep using what was built and the next step is worth financing.
• It forces precision early. A cap cannot be agreed without a baseline, success criteria and a risk budget, so those are written down in the first phase.
• It works as a filter. We only put our own contribution into cases where we believe the workflow matters and the software can be reused. Sometimes that means we propose a paid build, or decline.

The cap matters as much as the risk. An open-ended contribution is a subsidy with no agreed end.

How is a proof structured?

A proof runs in three consecutive phases and three workstreams, often around 90 days in total. The duration is set per project. Product, technology and the commercial relationship are tested together in every phase.

Phase 1: define and build

The product workstream chooses the workflow, the users, the baseline and the success criteria, and builds the first version. The technical workstream checks data, architecture, integrations and the fit with the Backbone. The business and partnership workstream works out the business case, the commitment, the risk budget and preliminary partnership principles.

Phase 2: use and improve

Real users test the product, and experience and usability improve. Integrations, human controls and administration are built and tested. On the business side we test commercial demand, unit economics and transferability to a next environment.

Phase 3: prove and decide

The product workstream evaluates value and adoption and defines the next product scope. The technical workstream tests repeatability, transferability, operating cost and the rollout path. The business and partnership workstream ends with a decision: stop, adjust or scale.

The third workstream is the one a technical pilot usually leaves out. A working workflow with no shared view on who finances, owns and operates the next step tends to end in another pilot.

What the capped contribution is, and what it is not

Before a proof starts we fix four things: what Nova invests, what is paid in cash, what may become a receivable and when the contribution stops. The contribution itself is a capped amount of senior time, product work and/or development at risk.

What it is not:

• Not a free proof. There is no standard free proof.
• Not a financing promise. There is no standard financing promise for what follows.
• Not a label for paid work. A fully paid proof is not a Nova investment simply because Nova works on it.
• Not automatic equity. Whether participation is part of the picture is decided later, on the evidence.

Paid build, risk-sharing proof or venture participation?

How we partner is one of three independent choices in every Nova project, next to how you build and what you use.

One thing does not change. The client owns its custom code and product-specific development, and Nova maintains and licenses the shared Backbone and reusable modules.

What does the last phase decide?

The last phase ends with a joint decision to stop, adjust or scale. Stopping is a legitimate outcome. If the decision is to scale, the follow-on model is chosen at that point.

The business case and the agreements decide the model. One rule keeps the accounting honest: the same development contribution is never counted in full as debt and in full as equity.

A longer path can follow, from product partnership to venture and possibly buy-and-build expansion. That is a follow-on path, not a second set of proof phases.

Why should the second environment cost less than the first?

A value-creation thesis rarely depends on one company. It depends on whether what worked here can be used somewhere else without paying for it twice.

Our answer is architectural. A product built on Nova Backbone starts from a shared foundation that covers the parts of a business application that are the same every time: access and permissions, workflows with human oversight, visibility and audit, administration, and APIs and developer tools. In the first environment those foundations are set up and the workflow-specific product is built on top. In a second environment the foundations already exist, and so do the generic parts of the workflow that proved out. What remains is the work that is local: data, integrations, rules and the people who use the product.

That is the reasoning, not a promise. The third phase tests it, and if a second environment would cost as much as the first, the proof should say so.

Two boundaries apply. Shared technology does not mean a shared customer database: each company runs in its own environment, with its own data. And it does not mean an automatic transfer of portfolio IP: software is reused where the portfolio companies concerned agree to it.

An example at proof stage: the specialist automotive aftermarket

One case we work on sits in the specialist automotive aftermarket. Specialist knowledge, catalogues and product and parts resolution are fragmented and handled manually. The founder brings domain expertise, an operating business and access to workshops and distributors. We bring the product and technical team, workflows on Nova Backbone and a contribution to the proof.

The proof examines two things: whether fragmented information turns into a validated solution, and whether the same workflow is usable outside one environment. The thesis has three possible steps: operational proof in the current business, a repeatable product or partnership, and the possible integration of acquired specialists. The case is at proof stage, so there are no results to report. Buy-and-build is a strategic possibility, not a realised acquisition programme. Our ventures page describes the case from the portfolio angle.

Where does a fund or portfolio company start?

With one portfolio company, one workflow that matters and real users. Agree the baseline, the success criteria and the risk budget before anything is built. If the value is already clear, a paid build is simpler and we will say so. If it is plausible but unproven, a proof with a capped contribution lets both sides find out at a known cost. If you have a workflow or a thesis in mind, discuss a first proof with us.