recurring-revenue

Designs the recurring revenue layer for hardware companies: software license, maintenance and support, consumables, professional services, and data/insights tiers. Models LTV, defines the Year-1 bundling strategy, and builds the commoditization defense. A hardware company that sells only hardware has a lumpy, non-compounding revenue model. This skill designs the software moat.

Ir para a instalação

Repositório: 0xF4ng/aether-growth-fieldwork
Última atividade na origem: 17 de julho de 2026 às 16:44
Idioma detectado do SKILL.md: inglês
Estrelas: 5
Forks: 0

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Voltar à pesquisa Voltar à instalação

name	recurring-revenue
description	Designs the recurring revenue layer for hardware companies: software license, maintenance and support, consumables, professional services, and data/insights tiers. Models LTV, defines the Year-1 bundling strategy, and builds the commoditization defense. A hardware company that sells only hardware has a lumpy, non-compounding revenue model. This skill designs the software moat.
triggers	["/recurring-revenue","user wants to add a software or service layer to a hardware product","hardware company is facing pricing pressure or margin erosion","user is designing the first contract structure for a new hardware product","pilot-to-production transition requires contract design"]
role	hardware-gtm
version	1.0.0
sources	["hw-recurring-revenue-design (growth-skills v1.0, score 8/10)","Manufacturing GTM frameworks (2026)"]
feeds	["hardware-gtm/poc-pilot"]
related	["hardware-gtm/channel-strategy","hardware-gtm/launch","pmm/icp-research"]

Recurring Revenue

Before starting

Confirm (ask or infer) before running:

Revenue model today — hardware-only / hardware + some services / no recurring revenue?
Installed base — how many units are deployed? (determines which recurring components are actionable now)
Software layer status — does any customer-facing software exist today? (remote monitoring, dashboard, firmware updates)
Competitive pressure — is there a lower-priced competitor threatening hardware margin?
Contract stage — designing the first contract / redesigning existing contracts / retroactively adding recurring to existing customers?
Customer type — single-site / multi-site / enterprise fleet? (determines which tier to prioritize)

Contract

This skill guarantees:

Every revenue component is assessed with its realistic gross margin (not blended hardware margin)
Year-1 bundling strategy is specified — whether to bundle software and maintenance into hardware price or invoice separately
LTV model uses real or estimated inputs — assumptions are stated explicitly
Commoditization defense is named specifically (not "we have a moat" without the mechanism)
The output distinguishes what to introduce immediately vs. what requires installed base scale

Role: Revenue Architect. A hardware company that sells only hardware has a lumpy, non-compounding revenue model. Revenue resets near zero every quarter. Every pricing conversation is a discount conversation. The software and service layer is not a nice-to-have — it is the moat against commoditization and the mechanism that turns hardware margin into compounding LTV.

Inputs

Required before proceeding:

Hardware list price and current gross margin
Units deployed (current installed base)
Whether any customer-facing software exists
Target gross margin for the business overall

Step 1 — Revenue component assessment

REVENUE COMPONENT TAXONOMY

Component          | Margin    | When to introduce        | Priority
Hardware           | 30–55%    | Day 1                    | Table stakes
Software license   | 70–85%    | Introduce in first contract | P0
Maintenance/support| 40–60%    | Annual; with hardware sale  | P0
Professional svcs  | 20–35%    | Project-based; as needed    | P1
Consumables        | 50–70%    | If BOM has repurchase items | P1
Data and insights  | 80%+      | After sufficient installed base | P2 (requires scale)

PRIORITY RATIONALE:
Software license and maintenance/support are P0 because:
  - Both are high-margin
  - Both are introducible immediately (no installed base required)
  - Both set the expectation for recurring revenue before the customer's mental model hardens
  - Once a customer has paid hardware-only for 2 years, introducing recurring is a "new ask"
    that meets resistance. Introduce at first contract.

Data and insights is P2 because:
  - Requires enough installed base to provide meaningful benchmarking
  - Anonymous fleet benchmarking only works if the fleet is large enough
  - Premature launch = thin dataset = customer doesn't renew

IMMEDIATE ASSESSMENT:
  For each component, mark: Active / Designable now / Requires development / N/A
  Only include components in the contract that are Active or Designable now.
  Do not promise components under development as part of a current contract.

SOFTWARE LAYER DESIGN — what to build for renewal

High-renewal software features (customer uses daily):

Feature                    | Why it drives renewal
Remote monitoring/dashboards | Ops teams want visibility without being on the floor;
                             | daily-use software stays in the budget
Predictive maintenance alerts| Reduces unplanned downtime — the highest-cost problem
                             | in manufacturing; value is visible and quantifiable
Performance benchmarking     | Customers want to know how their system compares;
                             | benchmarking is only valuable inside the network
Fleet management             | Managing 50+ units without software is impossible;
                             | creates natural enterprise tier and expansion path
OEE tracking                 | Factory managers report Overall Equipment Effectiveness;
                             | tools that calculate it automatically are daily-use
Software updates             | New capabilities + safety patches; customers on support
                             | get updates; those who aren't, don't

ANTI-PATTERN: building software that only the vendor uses.
  Diagnostics for your support team ≠ customer-facing software.
  Software that lives on the customer's operations dashboard gets renewed.
  Software on your engineering laptop does not.

MINIMUM VIABLE SOFTWARE LAYER (for early-stage companies):
  Start with: remote monitoring dashboard + predictive maintenance alerts
  These two features are:
  - Universally applicable across hardware categories
  - Buildable on top of existing sensor/telemetry data
  - Demonstrably valuable within the first month of deployment
  - Sufficient to justify an annual license fee at launch

YEAR-1 BUNDLING DECISION

Two approaches:

Option A — BUNDLE (recommended for early-stage companies)
  Bundle first year of software license and maintenance into hardware list price.
  Invoice as: "Hardware [list price] — includes Year 1 software and maintenance"
  Year 2 renewal invoiced separately at full annual rate.
  
  Why:
  - Removes "total cost" objection at purchase
  - Builds 12 months of software familiarity before the renewal conversation
  - Sets the expectation that renewal is standard, not a new charge discovered at year-end
  - Eliminates the "can we just not renew the software?" objection at year-end
    (if they've used it for a year, the answer is usually no)

Option B — SEPARATE (appropriate when software is already an established product)
  Invoice software license and maintenance as separate line items from Day 1.
  Advantage: makes software value visible from the start; clearer reporting.
  Risk: gives customer an obvious line item to remove at contract review.

DECISION LOGIC:
  IF software is new and not yet proven in customer hands → Option A (Bundle)
  IF software has proven renewal rate (>70%) in existing accounts → Option B (Separate)
  IF customer is price-sensitive and hardware deal is at risk → Option A (Bundle)
  IF customer is enterprise with line-item procurement requirements → Option B (Separate)

MAINTENANCE RATE STANDARD: 15–20% of hardware list price per year
  Below 15%: underselling; does not cover real support cost at scale
  Above 20%: common in high-reliability or safety-critical hardware
  For software-only maintenance: 18–22% of software license value

LTV MODEL INPUTS

Variable                        | How to model
Hardware revenue per unit       | One-time; discounted for large orders (document discount floor)
Software ARR per unit           | Annual license × units deployed; grows with installed base
Maintenance ARR per unit        | Annual rate (15–20% of HW list price) × units deployed
Gross retention rate            | % of software/maintenance ARR that renews
                                | Benchmark: 85–90% for manufacturing software
Net revenue retention           | Gross retention + expansion from new units at same account
                                | Benchmark: 105–115% for hardware+software bundles
Consumables ARR per unit        | Usage rate × repurchase price × units (if applicable)

LTV FORMULA:
  Hardware margin = Units × (List price × HW gross margin %)
  Software ARR = Units × Annual license × (Gross retention rate ^ year)
  Maintenance ARR = Units × (HW list × 17.5%) × (Gross retention rate ^ year)
  
  LTV (5-year) = Hardware margin + Σ(Years 1–5)[Software ARR + Maintenance ARR]

SENSITIVITY INPUTS TO DOCUMENT:
  - What is the LTV difference between 85% and 90% gross retention?
  - What is the LTV difference between $Xk and $Yk annual software license per unit?
  - At what installed base does data/insights tier become feasible?

NOTE: Do not present LTV projections as commitments. Document assumptions explicitly.
LTV is a planning tool, not a sales promise.

WHEN A COMPETITOR OFFERS EQUIVALENT HARDWARE AT 30% LOWER COST

Defense Mechanism 1 — Installed base switching costs
  2 years of historical production data + trained operators + MES/ERP integration
  = customer's cost to switch exceeds the hardware price difference
  
  Articulate to customer: "Switching to [competitor] means losing [N months] of
  performance data, retraining your operators, and re-integrating your [system].
  What is that worth per hour of downtime during the transition?"

Defense Mechanism 2 — Application-specific optimization
  Software tuned to the customer's exact application (their parts, their cycle,
  their quality specs) is not replicable by a new entrant.
  
  Build this explicitly: customer-specific parameter profiles, application-tuned
  vision models, custom reporting tailored to their KPIs.

Defense Mechanism 3 — Network effects in benchmarking
  If your software benchmarks each customer against the anonymized installed base,
  customers in the network benefit from collective intelligence.
  A new entrant cannot replicate this immediately.
  
  Requires: enough installed base to be statistically meaningful (rule of thumb: 20+ sites)

Defense Mechanism 4 — First-mover on integration
  Be the first vendor integrated with the customer's ERP, MES, or quality management system.
  Integration is expensive to replicate — for the customer and the competitor.
  
  Articulate to customer: "We are already integrated with your [system].
  A replacement vendor starts that integration from scratch."

DEFENSE MECHANISM APPLICABILITY:
  IF installed base per account < 2 years → Mechanism 1 is weak; focus on 2 and 4
  IF software usage is low → Mechanism 2 is weak; improve software adoption first
  IF installed base < 20 sites → Mechanism 3 is premature; do not promise benchmarking
  IF integration is not complete → Mechanism 4 is not yet a defense

## Recurring Revenue Design

**Company/product:** [Name]
**Current model:** [Hardware-only / Hardware + some services]
**Installed base:** [N units at N sites]

### Revenue component status
| Component | Gross margin | Status | Year-1 action |
|---|---|---|---|
| Hardware | [X%] | Active | Baseline |
| Software license | [X%] | [Active / Designable now / Requires dev / N/A] | [Bundle into HW / Invoice separately / Build first] |
| Maintenance/support | [X%] | [Status] | [Action] |
| Professional services | [X%] | [Status] | [Action] |
| Consumables | [X%] | [Status] | [Action] |
| Data/insights | [X%] | [Status — likely N/A until scale] | [Action] |

### Year-1 bundling decision
Approach: [Bundle / Separate]
Rationale: [2 sentences]
Maintenance rate: [X% of hardware list price]

### Software layer design
Immediate (build/include now): [Features]
Phase 2 (when installed base reaches [N]): [Features]

### LTV model (5-year)
Assumptions: [State all inputs explicitly]
Hardware margin per unit: [$X]
Software ARR per unit: [$X/year]
Maintenance ARR per unit: [$X/year]
Gross retention assumption: [X%]
LTV per unit (5-year): [$X]

### Commoditization defense
Active defenses: [Which mechanisms are currently active]
Mechanisms to build: [Which mechanisms require investment]

Anti-pattern	Why it fails	Fix
Selling hardware-only and planning to add recurring later	"Later" is always a new ask that meets resistance; mental model has hardened	Introduce software and maintenance at the first contract
Building software only your support team uses	Software on your engineering laptop doesn't get renewed	Build for the customer's daily operations dashboard
Announcing a data/insights tier before sufficient installed base	Thin dataset = low value = no renewal	Launch data/insights only when installed base provides statistically meaningful benchmarking
Setting maintenance rate below 15% of hardware list price	Does not cover real support cost; leaves money on the table	Minimum: 15% of hardware list price for hardware maintenance
Treating professional services as a margin play	Professional services margin (20–35%) is the lowest tier; using it to win hardware deals destroys blended margin	Never discount professional services to win a hardware deal
Invoicing software separately before renewal rate is proven	Customer removes it at contract review	Bundle Year 1; prove value; invoice separately at Year 2+
Describing commoditization defense as "our relationships"	Relationships are not a defense against 30% price difference	Name the specific switching cost mechanism: data, integration, application tuning

Benchmark	Value	Notes
Hardware gross margin (industrial / manufacturing hardware)	30–55%	Varies by complexity and volume
Software license gross margin	70–85%	At scale; lower early-stage if support is bundled
Maintenance/support gross margin	40–60%	Depends on support intensity and headcount
Maintenance rate standard (% of hardware list price / year)	15–20%	Below 15%: underselling; above 20%: common in safety-critical
Gross retention rate (manufacturing software)	85–90%	Annual renewal rate; below 80% indicates software isn't being used
Net revenue retention (hardware + software bundle)	105–115%	Expansion from new units at same account
Minimum installed base for data/insights tier	20+ sites	Below this: benchmarking dataset is too thin to be valuable
LTV multiplier (hardware-only vs. hardware + 5yr recurring)	2.5–4x	Highly variable; depends on software ARR per unit and retention

Skill	When to use
`hardware-gtm/poc-pilot/SKILL.md`	Pilot-to-production transition: recurring components go in the first contract
`hardware-gtm/channel-strategy/SKILL.md`	Channel partner contracts must include the recurring component structure
`hardware-gtm/launch/SKILL.md`	Product launch: recurring revenue components are part of the launch brief
`pmm/positioning/SKILL.md`	Positioning for a hardware+software bundle is different from hardware-only positioning