| name | ict-product-company-business-plan |
| description | Use when generating or reviewing a business plan for a non-SaaS ICT product company selling licensed software, embedded systems, hardware-software products, or on-premise systems; use `ict-services-firm-business-plan` for project-led services and SaaS skills for subscriptions. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
ICT Product Company Business Plan Skill
Overview
Not every ICT plan is SaaS. Licensed-software, embedded-systems, hardware-plus-software, and on-premise enterprise-software companies have a fundamentally different economic model. This skill produces the plan for that company profile, with explicit guidance on the SaaS-transition path that most of these companies should plan over time.
Use When
- Product is sold as a one-time licence (perpetual or term)
- Product has a hardware component (M-KOPA, BasiGo, Sun King, Helium)
- Product is on-premise enterprise software
- Hybrid (one-time licence + recurring maintenance + optional SaaS layer)
Do Not Use When
- Pure SaaS (use SaaS skills)
- Pure services (use
ict-services-firm-business-plan)
Required Inputs
- Product description and revenue model (licence + maintenance / hardware + service)
- Unit pricing and cost
- Sales cycle and channels
- Manufacturing / supply-chain (if hardware)
- Maintenance / support cost profile
Workflow
- Define the revenue model:
- Perpetual licence + annual maintenance (15-25% of licence fee)
- Term licence (1-3 years)
- Hardware-plus-software bundle (one-time + recurring service)
- PAYG / financed (M-KOPA model)
- Compute the unit economics:
- Revenue per unit (one-time + recurring components)
- Cost per unit (hardware BOM if applicable; software COGS; install/onboarding)
- Gross margin (typically 40-65% for hardware-inclusive; 50-75% for pure licensed-software)
- Maintenance attach rate (target 90%+)
- Maintenance renewal rate
- Plan the SaaS-transition path (most of these companies should plan one):
- Phase 1: Pure perpetual + maintenance (current)
- Phase 2: SaaS offering for new customers (some cannibalisation acceptable)
- Phase 3: Migrate existing customers to SaaS
- Mersch's perpetual-vs-SaaS chapter is the source
- Compute the financial profile:
- Higher one-time revenue per customer than SaaS
- Lumpier cash flow (large up-front + smaller recurring)
- Different working-capital pattern (no Working Capital Trough but unit costs)
- Inventory if hardware
- Hardware-specific considerations:
- BOM (Bill of Materials) cost
- Manufacturing partner / EMS
- Supply-chain (Africa: shipping, customs, FX-on-import)
- Inventory management
- Field-service / repair operation
- Design the sales motion — typically channel + direct, longer cycles, RFP-friendly.
- Plan the productivity moat — how does the product avoid commoditisation?
Quality Bar
- Unit economics computed per unit, not aggregate
- Maintenance attach + renewal rate explicit
- SaaS-transition path planned (or explicit reason not to)
- Hardware supply-chain modelled (if applicable)
- Sales cycle and channel structure designed
- Cash flow recognises lumpy nature
Anti-Patterns
- Treating one-time licence as if it were ARR (it isn't)
- Hardware product without supply-chain plan
- No maintenance / support contract structure
- "We'll convert to SaaS later" without roadmap
- Underestimating field-service / repair cost
- Ignoring FX on imported hardware
Outputs
- Unit-economic model per product
- Revenue model (licence + maintenance / PAYG / etc.)
- SaaS-transition roadmap (or rationale for not transitioning)
- Hardware supply-chain plan (if applicable)
- Sales motion and channel structure
- Financial profile distinct from SaaS
References
book-extractions/mersch-hacking-saas-extraction.md — perpetual vs SaaS comparison (ch. 1)book-extractions/tod-building-multi-tenant-saas-architectures-extraction.md — MSP vs SaaS claritybook-extractions/haines-how-to-create-a-business-case-extraction.md — business-case discipline for product investmentsskills/ict-services-firm-business-plan/SKILL.md — sister skillskills/saas-unit-economics-and-cohort-model/SKILL.md — for SaaS-transition modelling
Africa / Uganda Application Notes
- Hardware-inclusive plans are a major African opportunity (energy access M-KOPA / Sun King / Zola; e-mobility BasiGo / Ampersand; agritech tools Hello Tractor).
- PAYG financing is a powerful African model — combines hardware + software + financing.
- Customs duty, VAT, and shipping costs are material — model explicitly.
- Local assembly often required for tax / local-content reasons — plan partner relationships.
- Field-service network is a real capability (M-KOPA built ~3,000 field agents in Kenya).
- Mobile-money integration is standard for PAYG.
- Public-sector procurement of on-premise software has specific compliance (data localisation, security certification) — plan early.
- The transition from licensed-software to SaaS is harder in African enterprise markets where data-residency concerns and unreliable connectivity favour on-premise.
Inputs
| Artefact | Source or provider | Required? | If absent |
|---|
| Product architecture, bill of materials, licences, roadmap, support, installation, and lifecycle evidence | Founder, product, engineering, supplier, and customer records | Required | Return a discovery gap list, not a complete plan |
| Customer, competitor, procurement, channel, pricing, pipeline, and adoption evidence | Primary research and verified market sources | Required | Qualify demand and avoid invented market figures |
| Revenue, inventory, warranty, maintenance, FX, tax, and cash-flow treatment | Chwezi Accounting Doctrine and finance records | Required for projections | Stop financial conclusions until doctrine and model reconcile |
Outputs
| Artefact | Consumer | Acceptance condition |
|---|
| ICT product-company plan input pack | Business-plan pipeline, founder, lender, or investor | Product, market, delivery, support, economics, funding, and risks reconcile |
| Product economics and lifecycle assumptions register | Finance, product, operations, and investor reviewers | Each price, unit cost, licence, warranty, support, replacement, and capacity assumption has evidence or a range |
Evidence Produced
| Evidence | Format | Acceptance condition |
|---|
| Product-to-commercial traceability | Feature, customer problem, evidence, price, delivery, support, and risk matrix | Every roadmap and revenue claim links to customer and operating evidence |
| Finance quality-gate result | Doctrine mapping, reconciled model, and professional-review status | Revenue, COGS, inventory, warranty, maintenance, tax, and cash treatment pass the Chwezi gate |
Capability Contract
Analysis defaults to read-only. Edit the plan only when authorised. Do not alter product systems, supplier orders, pricing, contracts, production, customer data, or financial records; spending, launch, certification, legal, security, and accounting claims require explicit authority and qualified review.
Degraded Mode
Without product evidence, customer research, supplier quotes, current sources, or a reconciled finance model, return a qualified plan module and validation backlog. Mark affected checks not assessed and do not convert a prototype, letter of intent, or scenario into proven demand or revenue.
Decision Rules
| Choice | Action | Failure or risk avoided |
|---|
| Value is delivered mainly by one-time software or hardware sale | Use product and lifecycle economics | Misapplying SaaS metrics |
| Delivery depends mainly on billable projects | Route to ict-services-firm-business-plan | Hiding utilisation constraints |
| Value and payment are recurring subscriptions | Route to the SaaS plan stack | Wrong revenue and retention model |
| Revenue or cost treatment is material | Apply Chwezi doctrine and professional review | Misstated projections |
Workflow
- Classify the offer as licensed software, embedded, hardware-software, on-premise, or hybrid; stop if SaaS or services dominates.
- Gather product, customer, channel, procurement, supplier, implementation, support, roadmap, and risk evidence.
- Map the product lifecycle from manufacture or development through installation, warranty, maintenance, upgrade, and retirement.
- Build pricing, unit cost, capacity, working-capital, support, and replacement assumptions under current Chwezi doctrine.
- Reconcile market, operations, staffing, funding, and financial sections with the product roadmap.
- Stress supplier, FX, defect, warranty, adoption, procurement-cycle, certification, and obsolescence cases.
- Recover from missing evidence by narrowing claims and adding dated validation actions.
- Release the module only after business-logic, finance, evidence, risk, and anti-slop gates pass.
Quality Standards
The plan must show why the product wins, how it is built or sourced and supported, how each unit contributes cash, and how funding bridges the lifecycle. Current claims and finance treatments must be verified or qualified.
Anti-Patterns
- Treating a perpetual licence as monthly recurring revenue. Fix: separate licence, implementation, maintenance, and upgrade streams.
- Ignoring hardware replacements and warranty returns. Fix: model failure, replacement, service, and reserve assumptions.
- Calling a prototype a market-ready product. Fix: state readiness evidence, certification, backlog, and launch gates.
- Using one supplier quote as a permanent unit cost. Fix: date it, include FX, lead time, minimum order, and sensitivity.
- Forecasting sales without procurement-cycle evidence. Fix: model decision makers, trials, approvals, and payment timing.
- Finalising revenue or inventory treatment without Chwezi review. Fix: retain the doctrine map and professional sign-off status.
Worked Example
An on-premise school-management product charges a licence plus installation and annual maintenance. Model those streams separately, include deployment capacity and support cost, and do not route it to SaaS unless recurring access is the dominant product and economic model.
