In short: pick the revenue model by who carries the capital and the service tail, price pilots and production differently, and report only what would survive due diligence.
Key points
- Hardware-as-a-service works only with a financing partner behind it; otherwise each unit consumes equity.
- Outcome or usage pricing needs a measurement the buyer trusts and enough deployment history to price risk.
- Using equity to fund fleet deployment is the most common and most expensive mistake in the vertical.
- Price pilots as fixed-fee projects with a success test and a stated conversion price; free pilots teach nothing.
- Stop reporting letters of intent, pipeline value and undelivered orders; report converted pilots and contracted annual value.
Five models, one question
Every emerging tech revenue model answers the same question: who carries the capital and who carries the risk of the thing not working. Match the model to the answer your buyer and your balance sheet can live with.
Hardware plus service is the default. The buyer pays for the unit upfront and a recurring fee for software, monitoring, maintenance and updates. Capital sits with the buyer. Your margin is visible on day one. The weakness is that the upfront price triggers capex approval, which is often the slowest door in the building.
Hardware-as-a-service moves the unit onto your balance sheet and charges a monthly or annual fee. The buyer's capex problem disappears. Yours appears. This model works only with financing behind it: equipment finance, a leasing partner or a project finance vehicle. Without that, every unit you deploy consumes equity, and Part 32's runway maths breaks.
Outcome or usage pricing charges per inspection, per kWh delivered, per verification, per task completed. It aligns you with the buyer completely. It also requires two things most early companies lack: a measurement the buyer trusts and enough deployment history to price the risk. Use it only when both exist, and expect to start with a floor fee.
Licensing and royalties suit IP-heavy companies with an OEM route, as Part 34 described. Low margin per unit, no service tail, wide reach. Pair a licence fee with a per-unit royalty and a minimum commitment.
Network or token models apply to DePIN and only if Part 17's test is passed: the token must do a job the network cannot do without it. If it fails that test, it is a financing mechanism dressed as a revenue model and will be priced as one.
Gross margin and the service tail
The number that decides whether any of this works is gross margin per unit including the service tail. Not hardware margin. Not software margin. The blended number after field service, spares, remote monitoring, firmware support and the hours a customer success engineer spends on site.
Most emerging tech companies know their bill of materials and guess their service cost. Measure it from the first deployment. Log every site visit, every spare, every support hour against the unit it served. After ten units you will have a real number. It will be worse than the model. That is fine. Price the next contracts on it.
| Model | Who carries capital | Service tail risk | Needs |
|---|---|---|---|
| Hardware plus service | Buyer | You, priced in | Clear unit economics |
| Hardware-as-a-service | You | You | Financing partner |
| Outcome or usage | You | You | Trusted measurement |
| Licence and royalty | OEM | OEM | Protected IP, minimums |
| Network or token | Network | Operators | Part 17's test passed |
Project finance or equity
Part 32 covered the capital stack. The revenue model decides which layer pays for what.
Equity pays for things that reduce technical and commercial risk: engineering, the first deployments, the playbook. Project finance or asset finance pays for things that are already de-risked: the fiftieth unit of a design that has run for a year at three sites. Using equity to fund fleet deployment is the most common and most expensive mistake in this vertical. Using debt before the design is stable is the second.
The line between them is the same success test from Part 33. Once a deployment has passed it, the unit is a financeable asset. Before that, it is research.
Pilots as projects, production as contracts
Price a pilot as a project. Fixed scope, fixed fee, fixed duration, a defined success test and a stated conversion price if it passes. The fee should cover your cost. A free pilot teaches the buyer that your product is worth nothing and teaches you nothing about their procurement.
Price production as a contract with a term. A minimum number of units or sites, a minimum duration, a service level, a renewal clause and an exit cost. The term is what makes contracted annual value a real number and what makes the business financeable.
Never let a pilot drift into production on pilot terms. Set the conversion date in the pilot agreement.
What to report, and what to stop
Part 9 said stop reporting reach. For emerging tech, the equivalent is to stop reporting intent. Report what has happened.
Report paid pilots converted to contracts, as a count and a rate. Contracted annual value, with term. Gross margin per unit including service. Deployment lead time from signature to commissioning. Uptime or performance against the success test, per site. Risk retired this quarter, in plain words.
Stop reporting letters of intent, pipeline value, and units "ordered" with no deposit and no delivery date. Each is a story about the future. Investors have heard the story. Customers never see it. Neither will pay for it.
The checklist
- [ ] The revenue model is chosen by who carries capital and who carries the service tail
- [ ] Gross margin per unit includes measured service cost from real deployments
- [ ] Hardware-as-a-service or outcome pricing has a financing partner or a trusted meter behind it
- [ ] Pilots are priced as projects with a success test and a conversion price
- [ ] Production contracts have a term, minimums, service levels and an exit cost
- [ ] The board pack reports converted pilots, contracted annual value and margin, and nothing about intent
Closing the series
Thirty-five parts come down to one page.
The spine applies everywhere. One system, not three problems. One product truth, a belief per audience, a claims register. Raise against evidence. Run the round like a sales process. Treat community as a job. Earn the first hundred. Make the first ten customers design partners. Build distribution because the platforms are closed. Stop reporting reach. Build it to run without you.
Each vertical changes four things and leaves the rest alone.
| Vertical | Who buys | What proof counts | Which channels are open | What to measure |
|---|---|---|---|---|
| AI | The team that owns the workflow, then the budget holder | Output quality on the buyer's own data, a security pack that passed review | Marketplaces, developer communities, answer engines | Retained paid teams, gross margin, cost per task |
| Crypto | Users with funds at stake, then integrators, allocators and holders | Retained usage without incentives, named and dated audits, a token with a job | Issuers, integrations, curators, ecosystems | Protocol revenue, retained deposits, incentive cost per sticky dollar |
| Fintech | The person trusting you with money, and the compliance owner behind them | Licences, the custodian, loss ratios, funded accounts that stay | Partners who hold the customer, practitioners, comparison sites | Funded accounts, cost per funded account, 90-day retention |
| Media | Readers first, then sponsors, licensees and data buyers | Owned audience, paid conversion, renewal, sponsor results | Owned lists, membership, being the cited source, events | Paid conversion, churn, revenue per subscriber, platform independence |
| Emerging Tech | The cost owner, reached through integrators, OEMs and consortia | Field deployments that passed a success test, risk retired | Integrators, OEMs, platform programmes, standards bodies | Converted pilots, contracted annual value, margin including service |
The order matters more than any tactic. Product truth before the pitch. Evidence before the raise. Design partners before the channel. Direct before partners. Pilots before contracts. Measurement before reporting. Every failure we have seen in this series came from doing a right thing at the wrong time.
If you are not sure where you are in the order, score yourself against the ten questions in Part 10. Then bring us the commercial problem. That is what lowob is for.
Common questions
How should a hardware startup price a pilot?
As a project with fixed scope, fee and duration, a defined success test and a stated conversion price. The fee should cover cost, and the conversion date should be set in the pilot agreement.
When does hardware-as-a-service make sense?
Only with financing behind it, such as equipment finance, a leasing partner or a project finance vehicle. Without that, every deployed unit consumes equity.
Should deep tech companies use equity or project finance for deployments?
Equity should fund what reduces technical and commercial risk. Project or asset finance should fund units of a design that has already passed its success test.
What should emerging tech companies report to their board?
Converted pilots as a count and rate, contracted annual value with term, gross margin per unit including service, deployment lead time, performance against the success test and risk retired. Not letters of intent or pipeline value.