The Software Changed. The Decision Architecture Survived.

What an origin case is. This is not a Journey chapter, and it is not a validation case. It describes work done years before Adaptive Thinking existed as a named method. The method did not shape this work — it was later recognised inside it. Where the evidence is strong, this case shows what held together across four different systems. Where the evidence is still incomplete, that is marked plainly rather than smoothed over.

THE CASE

1. 01 · Starting From Zero
2. 02 · From a Calculator to a Process
3. 03 · One Core, Three Market Realities
4. 04 · From Central Control to Distributed Capability
5. 05 · An Independent Test, Not Yet a Proven One
6. 06 · What This Case Demonstrates — and What It Does Not
7. 07 · What This Case Later Revealed

01

Starting From Zero

Planet Car Lease was building a full-service leasing business with no dedicated pricing system. The tool was Excel, but the real work was designing the commercial and operational logic of the business from scratch — what information a pricing decision actually needed, and when.

The first calculator brought together data that normally sits in separate functions: vehicle data, financing calculations, residual-value estimates, maintenance cost per kilometre, insurance and additional services, contract terms, and effective profitability at contract level. From the same data, it could also generate the offer, contract, vehicle order, notification and handover protocol — pricing and execution sharing one source of truth instead of being re-entered at each stage.

One design choice mattered more than it looked. Traditional fleet-management systems typically require a vehicle's exact configuration before they will calculate an initial quotation. This model separated the two: an initial price required only the total value of additional equipment. The full configuration became mandatory only once an offer was accepted.

Capture information when the decision needs it — not simply because a later step will.

The practical result was an offer preparation time that fell from roughly thirty minutes to under five, and — just as importantly — the ability to produce several pricing variants in that time instead of one.

02

From a Calculator to a Process

The logic moved into a web platform. It kept the same calculation model but placed it inside a controlled operating environment: customer, supplier, vehicle and user databases; defined roles and authorisation levels; frozen calculations that preserved the commercial assumptions behind a specific offer; versioning and recalculation when mileage, duration or equipment changed; and a direct, traceable link from an accepted offer through to the resulting contract.

This is the point where governance stopped being a separate approval step and became part of the process itself — visible in how the system behaved, not layered on top of it as an additional gate.

The web platform's logic later served as the reference model when pricing was implemented inside an ERP environment. The calculation assumptions transferred; the technology did not need to.

Governance stopped being an approval step layered on top. It became something the process did by design.

03

One Core, Three Market Realities

After the acquisition of regional operations in the Czech Republic, Slovakia and Hungary, buying full ERP functionality for each smaller operation would have been disproportionately expensive relative to their scale. The existing web platform offered a lighter, materially cheaper alternative — while keeping the same underlying calculation principles.

This was not one template copied across three countries. A common core was kept, and the decision logic was adapted where local reality required it: different currencies, different funding costs, local VAT and road-tax rules, market-specific products, and — most tellingly — materially different insurance-calculation methods. In the Czech market, insurance cost varied by vehicle brand and, for Škoda specifically, by individual model.

Standardise the decision logic. Adapt the execution to what local reality actually demands.

Before implementation, preparing a single offer in these markets took roughly 30–60 minutes. With the platform, users could produce four to eight variants for one vehicle in around five minutes.

Speed did not mean unrestricted freedom. An authorisation matrix tied the right to change assumptions to expertise and accountability: Sales could compare commercial variants but not alter key risk assumptions; an Operations Director could correct an unusually high service-cost entry; residual-value assumptions could only be changed by authorised specialists; certain calculations required sign-off from the CEE Sales Director.

This produced a working loop rather than a one-off fix: a local exception triggered expert review, which fed back into the shared database, which improved every future calculation — not just the one in front of the user. The tyre database is a concrete example: selection could not rely on size alone, so speed ratings, load ratings, and passenger-car/SUV differences were added progressively, as real cases surfaced gaps the first version could not have anticipated.

A local exception, reviewed once, became a correction every future user benefited from.

04

From Central Control to Distributed Capability

Early on, a single SuperAdmin role held systemic coherence: local anomalies, proposed rule changes and database corrections all returned to one point, where it was decided whether something was a one-off exception or evidence the model itself needed to change. That concentration protected consistency, but it also created a real dependency on one person.

As the system matured, that responsibility was distributed — roughly five users per country operating the platform, supported by around ten people in central and administrative functions, with database-management rights transferred into the organisation while defined regional approvals remained in place.

The platform kept operating after its original architect left. It was eventually retired when the subsidiaries were sold and migrated to ERP — not because the decision logic had failed, but because the ERP's own calculation model had been built on the same underlying assumptions. The application disappeared; the logic it encoded did not.

The role is unfinished if it only protects the system and never lets go of it.

05

An Independent Test, Not Yet a Proven One

In 2025, comparable thinking was applied again at Drivalia, in a different starting condition: pricing inputs were split across people rather than systems — one person calculated the financing rate, another supplied residual value, service and insurance inputs came from elsewhere again. Each contribution could be individually defensible; the complete offer still depended on multiple handovers and waiting time.

A new tool was built for Drivalia rather than reusing the earlier software, adapted to Drivalia's own product structure but keeping the same core design choices: shared calculation logic, connected data, visible profitability control, clear decision rights, and fast variant generation with genuine exceptions still escalated rather than absorbed silently. Preparation time is reported to have fallen from roughly three hours to around ten minutes.

This figure is not yet independently verified, and — as important — it does not by itself prove that the value came from cross-functional decision design rather than good conventional automation. What would make this a strong confirming case, and is not yet documented, is evidence of the harder part: whether the three hours were mostly calculation or mostly waiting and renegotiation between functions; how shared thresholds were actually agreed; whether anyone resisted losing a prior point of control; and whether the shared logic has held six months on, or shadow spreadsheets have started to reappear.

Until that evidence exists, Drivalia is a second real-world application of the same design instincts — not yet proof that they travel independently of the person applying them.

06

What This Case Demonstrates — and What It Does Not

It demonstrates: end-to-end process design organised around a decision, not around departmental handovers; governance built into roles, thresholds, versioning and escalation rather than added as a manual gate; one decision logic held consistent across functions, technologies and three national markets, without forcing every market into an identical model; a repeated loop in which local exceptions improved the shared system rather than being treated as one-off errors; a transfer of capability from a single original architect into an organisation, with an honest account of the dependency that existed before that transfer; and reuse of the same core design choices across four different pieces of software over nine years.

It does not yet demonstrate that this way of designing decisions produces better results independent of the person who designed it. The clearest test of that — the 2025 Drivalia reapplication — is the least verified part of this case, not the most.

07

What This Case Later Revealed

Read today, this case connects to elements later named through Adaptive Thinking — vocabulary that did not exist when this work was done, applied here as a mapping, not a claim that the method was consciously followed.

Preparing the Ground shows up in the shared calculation reality built across Sales, Finance, Operations and Risk from the very first version, in 2016: a price meant the same thing to everyone using it, long before anyone described that as a method.

The Adaptive Spiral shows up in the sequence itself — each version changed the operating reality and surfaced what the next version needed to handle: reality → what different functions saw → how those views connected → a clearer shared picture → a changed system → a new reality to work from. The tyre-database loop is this pattern in miniature.

Business System Architect describes the SuperAdmin role rather than a title anyone actually held. One person carried systemic coherence early on — decision rights, thresholds, versioning and escalation living inside the workflow rather than layered on top of it as separate approvals, and a consistency of decision logic held across functions, technologies and three national markets without forcing every market into an identical model. That coherence was unfinished work until it was deliberately distributed into the organisation, and unfinished again, in a different way, until the platform itself was retired.

Adaptive Thinking at Work is visible in the 2025 Drivalia reapplication as an early prospective use of comparable design logic in a different organisation. It offers evidence for the next turn, but it is not yet a Validation Case and does not prove that the logic travels independently of the person applying it.

I did not design Adaptive Thinking and then apply it here. I recognised it by looking back at how the work had already evolved.

Evidence note

The following figures are based on professional recollection, not a contemporaneous audit, and should be treated and presented as approximate:

• Offer preparation, 2016: approximately 30 minutes → under 5 minutes.
• CZ · SK · HU adaptation: 2020; offer preparation approximately 30–60 minutes → 4–8 variants in around 5 minutes.
• Drivalia, 2025 (most recent): approximately 3 hours → around 10 minutes. Not yet independently verified — see Section 05 for what would need to be true for this to confirm the method rather than simply confirm good automation.
• ERP reference point: the precise implementation date is not included because it has not been independently confirmed.

Company names are used selectively. The acquired regional operations and former owner remain anonymised, and commercially sensitive calculation assumptions are excluded.