Product · 2026
From client model to licensable product
The engine behind the pilot studies, rebuilt as the platform's first product built for licensing rather than for a single client.
year modelling horizon, discounted to present money
source systems reconciled in the data layer
tier subscription structure, replacing a tangled one
The brief
Two feasibility studies produced the same shape of model twice. The second one was faster than the first, but not fast enough to be a business. Turning the model into a product meant separating the parts that were genuinely general from the parts that only made sense for one operator.
The commercial case around it was mine as well: what it should cost, who else is in the market, and what it would take to fund the build.
Deliverables
Purchase premium, chargers, energy, servicing, road and weight taxes and residual value over a ten-year horizon, discounted to present money, with consumption derated for the Nordic climate and maintenance on a lifecycle curve.
A reconciled layer underneath the calculator drawing on telematics, ERP cost accounting, transport management records, fuel cards and the national vehicle registry, each source carrying a reliability grade.
The assumptions the model falls back on when a client has no measurement of their own, each with an explicit tolerance band instead of a single confident figure.
Market sizing built to withstand investor scrutiny rather than to impress, a competitor benchmark that was honest about where established platforms were still ahead, and a pricing analysis that replaced a tangled structure with a clean two-tier subscription.
Actions
Problems and solutions
Every project has these. They are more informative than the finished result, so they are on the page.
Problem
A model built for one client encodes that client's assumptions invisibly. Shipping it as a product would have shipped their operating pattern to everyone else.
Solution
Split the engine from the assumptions. Client-specific values became inputs, and everything the model still needs to assume moved into a named benchmark register with a tolerance band attached, so a user can see exactly which of their numbers are theirs and which are borrowed.
Problem
The tolerance bands were declared but never tested against reality.
Solution
Documented as declared intent rather than verified accuracy, pending a blind test, and marked that way in the repository so nobody downstream cites them as validated. A product that overstates its own precision fails once, publicly, in front of the client who relied on it.
Problem
The original pricing structure had accumulated tiers and options until it could not be explained in a sales conversation.
Solution
Replaced with two tiers. Most of what had been priced separately was either never bought or never refused, which meant it was not really pricing, it was decoration.
Outcome
The platform's first product built for licensing, with the pilot studies as its proof and a pricing and positioning case behind it.
What it took