Problem: there is no single pricing model
The price shown to a guest is assembled from layers with different timescales and owners: an asset base fare, duration and lead-time behaviour, slot-level demand and supply, product and flexibility context, feedback from conversion and revenue, asset-specific controls and approved business interventions.
I took ownership of an active ecosystem rather than a blank architecture. The goal was to make the system more coherent without breaking contracts that hosts, guests and downstream services already depended on. That required dependency mapping, narrow releases and operational documentation alongside modelling.
This article is intentionally public-safe. It explains the engineering decisions and lessons without exposing customer data, proprietary prompts, internal identifiers, operational commands or confidential decision thresholds.
- BASE FARERepresent the asset and depreciation
- BEHAVIOURApply duration, lead time and slot context
- PRODUCTRespect plan and flexibility economics
- ASSETApply bounded car-level adjustments
- CONTROLUse approved, time-bound interventions
Base fare and recommendation layers
Base fare represents the hourly economic anchor of an asset. I improved its source specificity with variant-level acquisition data and retained explicit fallback for incomplete mappings. Incremental jobs priced newly onboarded cars, while a separate comparison path handled meaningful changes to existing assets.
Host recommendations were ranges rather than one forced number. Behavioural range multipliers combined city, duration, product and flexibility context, then interacted with base fare. Hosts retained bounded control, while long-duration products included earnings protection so a discounted guest proposition did not silently violate host economics.
Dynamic pricing and feedback
Slot-level pricing combined forward demand, available supply, historical utilisation shape and configured premiums. Feedback evaluation examined movement in conversion and revenue per search, because either metric alone can reward the wrong outcome. A higher price may improve revenue per search while reducing bookings; a lower price may improve conversion while destroying value.
The services operated at different cadences. Treating schedules as part of the data contract was essential: a current slot multiplier over a stale base or range can create a technically valid but economically incoherent price.
Product and asset releases
I added explicit flexibility identity so limited- and unlimited-kilometre products could carry distinct recommendations. I also introduced a bounded asset-level multiplier with neutral onboarding, controlled bulk changes and an audit trail. Both changes followed the same principle: if a distinction changes economic meaning, it must appear explicitly in the data contract.
These layers avoided contaminating base fare with exceptions. They also made rollback understandable: a product mapping or asset multiplier could be reversed without reconstructing which hidden conditional had changed the final price.
Change management is part of the algorithm
Sales can create demand spikes that cause a dynamic system to raise prices and defeat the sale. Small markets may not support meaningful dynamic movement. Peak events may require a temporary premium. I formalised these as explicit change types with discussion, approval, execution, independent validation and an audit record.
I also mapped active schedules, data stores, topics, credentials and fallbacks before moving services between environments. A code comment saying ‘deprecated’ is weaker evidence than an active scheduler. Operational truth came from what actually ran.
Result and impact
The result was a more legible pricing operating system: more specific base-fare inputs, explicit product and asset dimensions, controlled interventions and clearer audit paths. The Goa base-fare automation is documented separately because it had its own source hierarchy, operating model and release story.
Operational predictability is a pricing feature. Every stale input, silent fallback or unclear override is experienced by someone as a price. Reliability means making each layer’s meaning, owner, cadence and recovery path visible.