Physical AI founders need to prove what each new customer costs

A physical AI business can sign another annual contract and become harder to scale.

The customer brings recurring revenue, but also a different robot, new calibration requirements and another engineering team to support. If delivery costs rise alongside sales, the subscription provides little evidence that the economics are improving.

For UK founders building robotics software, training data or testing services, that distinction belongs at the centre of the funding case. The useful question is how much work can be reused when the next customer arrives.

Variation between machines creates demand for specialist infrastructure. It can also increase the cost of delivering it. A product that works well on one configuration may require substantial engineering before it works on another.

That makes repeatable delivery a separate commercial achievement from repeat purchasing.

Recurring revenue needs a delivery explanation

Physical AI covers systems that perceive and act in the physical world. Suppliers may sell training data, software for managing robot recordings, simulation environments or tools that test performance before deployment.

These activities have different cost structures.

A software connector that works across several customers may require limited additional development. A collection programme may need more operators, equipment and supervision whenever demand grows. A simulation product may combine reusable software with expensive work recreating a particular environment.

An annual contract can contain several of these activities. Combining everything into one recurring revenue figure conceals which activity produces gross profit and which consumes delivery capacity.

A more useful management view separates revenue and direct delivery costs across software, services, data licences, hardware and compute. It then follows customers from implementation into ongoing use.

This shows whether later periods become more profitable or simply require a different mix of support.

Measure the output the customer accepts

For a data supplier, hours recorded can be a poor guide to commercial performance.

Recordings may fail quality checks, omit essential measurements or prove unsuitable for the customer’s robot. The relevant commercial measure is the fully loaded cost of producing output that meets the agreed specification.

Consider an illustrative supplier producing 10,000 training episodes in a month. The customer pays £10 for each accepted episode. Collection, equipment use, processing and quality assurance cost £60,000 in total.

Illustrative calculation. Rejected episodes earn no revenue. Direct delivery costs remain unchanged. Central overheads, tax and financing costs are excluded.

A fall in acceptance from 80% to 60% removes the entire gross profit, although production volume stays the same.

Rework would make the second outcome worse if it added cost without producing additional accepted output.

The practical response is to agree acceptance criteria before expanding capacity. Finance and technical teams should reconcile rejected output to its cause, cost and responsible process.

A dashboard that celebrates collection volume while omitting acceptance can encourage spending that produces no billable value.

Prove reuse in the next implementation

A founder can describe a product as standardised while engineers quietly rebuild parts of it for every installation. The evidence sits in implementation records.

For each deployment, track:

• Engineering days required.
• Time from project start to customer acceptance.
• Third-party costs.
• Support hours after launch.
• Components reused from previous installations.
• Customer-specific work that cannot be reused.

Separate reusable product development from bespoke delivery using a consistent policy. Otherwise, customer-specific engineering can disappear into the development budget and make contract margins look stronger than the underlying economics.

Then compare similar deployments.

A second installation using the same robot configuration should reveal whether prior work reduces effort. A different configuration tests how far that advantage extends.

Early implementation costs do not automatically invalidate a product. They may create components that become valuable across future deployments.

The test is whether subsequent customers benefit through lower delivery effort, faster acceptance or better performance. Those outcomes need records, rather than a forecast assuming margins improve with scale.

Treat cash exposure as part of contract design

Acceptable gross profit can coexist with an uncomfortable funding requirement.

Recruitment, equipment and collection may need paying for before a buyer approves the output. A change in specification can extend that gap or leave completed work without a purchaser.

For a supplier, the immediate task is to model cash by programme. Include mobilisation, equipment, production, rework, acceptance and collection of payment.

Stress-test what happens when acceptance takes longer or a customer postpones the start date. A contract that appears profitable on completion may still require more cash than the business can comfortably commit.

Contract discussions should address:

• Deposits that contribute to mobilisation costs.
• Milestone payments tied to defined deliverables.
• Clear acceptance criteria and review deadlines.
• Payment for changes to the agreed specification.
• Responsibility for delays outside the supplier’s control.

Commercial feasibility will depend on bargaining power, but the cash forecast should expose the consequences of conceding each term.

Hiring against an expected order needs a separate downside case from hiring against committed work.

Test what remains valuable as customers mature

A customer may initially outsource work because it lacks its own infrastructure. As its fleet and engineering team grow, it may develop the ability to perform that work internally.

That creates a question for the supplier: which part of the offering will the customer still need once its own capabilities improve?

Founders should examine renewals alongside the customer’s stage of development. Spending that continues after deployment provides different evidence from a one-off purchase made during an early development programme.

Track whether the customer:

• Renews the same product.
• Expands into another product or service.
• Reduces spending as internal capability grows.
• Stops buying once its own fleet produces sufficient data.

Expansion revenue becomes more informative when its source is understood. A larger bespoke project may increase account revenue without improving the repeatability of the underlying product.

Data reuse also deserves a commercial check. Possessing recordings does not, by itself, establish permission to use them for other customers or purposes.

Before treating a dataset as an asset capable of generating repeated licensing income, establish its permitted uses and obtain appropriate legal review.

Build the funding case around evidenced gross profit

Specialist collection and engineering services can be worthwhile businesses. Customers may pay well for scarce access, reliable execution or difficult technical work. Their financing case should reflect those economics.

Before the next funding discussion, prepare a schedule showing revenue and gross profit by activity, implementation effort by customer, accepted output where relevant, and cash committed before payment.

Identify which improvements have already occurred and which still depend on future product development.

Where costs remain high, explain what would reduce them. That might involve reusable connectors, automated quality checks, narrower customer requirements or a change in contract terms. Each improvement should have an owner, a cost and a measurable result.

A higher order book becomes more persuasive when the business can explain the resources needed to deliver it.

For physical AI founders, evidence that the next customer requires less bespoke effort provides a stronger foundation for a scalable software argument than the subscription label alone.

Preparing for a funding discussion

Consult EFC can help founders connect contract economics, cash forecasts and funding requirements before approaching investors or lenders.

Discuss funding readiness with Consult EFC.

Kish Patel ACA, ICAEW · Founder, Consult EFC

Over 12 years across Big Four audit, Investment Banking, and corporate advisory. Kish works with SaaS founders, tech companies, and ambitious UK SMEs from £1M to £50M in revenue on fundraising, valuations, exit planning, and financial strategy. ICAEW regulated. Big Four trained. Based in London.