Home · Work · Real Deal Car Rental Booking Platform
Case study
A rental booking platform and marketing site for a car, Jeep and UTV company in Aruba — quoting real prices for real dates, taking payment online and at the counter, and running the business behind the scenes.
Scope at a glance
The business had been advertising a single day rate while actually charging a seasonal, length-dependent one.
We built one pricing engine and gave it the last word.
Customers are quoted a price the business can stand behind, and the counter runs the day from the same system that took the booking.
Real Deal rents cars, Jeeps, vans and UTVs to visitors arriving by plane and cruise ship, with free delivery to hotels, the airport and the cruise port. We built the booking platform the customer uses, the marketing site that feeds it, and the back office the team runs the day from. The two sites share one source of truth: the site reads its fleet and its prices live from the booking system, so a vehicle removed in the admin leaves the website on its own.
The business had been advertising a single day rate while actually charging a seasonal, length-dependent one. A customer wrote in quoting the advertised price against a much larger quote for a short trip — and he was right. Any honest fix had to start by deciding what a price even means when the rate falls the longer you stay, then make every screen, quote and contract agree on it.
We built one pricing engine and gave it the last word. It prices each day of a rental at that day's own season and applies a duration ladder across the whole stay, so a two-day trip and a two-week trip get genuinely different per-day rates. Then we made the marketing site refuse to advertise a number the visitor cannot actually buy: a rate is published only if it holds across a short trip, a long trip and peak season, and otherwise the site quotes the visitor their own dates instead. The same engine drives the booking flow, the staff booking form and the customer quote.
Customers are quoted a price the business can stand behind, and the counter runs the day from the same system that took the booking. Both the booking platform and the marketing site are live and in daily use.
The heart of this build is a rate that moves with the season and the length of the trip. Every figure below was read from the live booking API, not modelled — each chart says when it was taken, and the numbers behind it can be opened.
Screens captured from the running system, not mockups.
The decisions that took the longest to get right, and why they went the way they did.
The marketing site, the public booking flow and the staff booking form all need a price. Written three times they drift, and the drift is invisible until a guest quotes one screen at another. All three call the same engine, and the rental agreement is generated from the same result, so no screen can show a number the contract does not recognise.
Because the per-day rate falls with trip length, no single number is true for every booking. The marketing site now probes a short trip, a long trip and peak season, and publishes a rate only when all three agree. When they disagree it says nothing and sends the visitor to quote their own dates — which is why some cars show a price and others deliberately do not.
A pickup at 8:00am returning 4:00pm seven days later is eight rental days, not seven and a third. That rule has to hold in the quote, the extension, the late-return charge and the invoice, or two screens disagree about a real amount of money. It lives in one function that all of them call.
A card payment at the desk carries a processing fee. Storing the rental amount rather than the amount actually charged left a phantom balance the size of the fee on every card booking. Card rows are stored gross — what the terminal took — and the fee is separated for reporting instead of being quietly netted off.
Two staff editing the same booking, or a payment landing while someone edits it, can each read a balance and write back a total computed from a stale one. The money paths run in serializable transactions with a retry, so the second writer is made to re-read rather than overwrite.
A guest asked how he was meant to know that extra protection had been added — the total moved but nothing said why. The rental agreement now itemises the charge: the rental, each protection, each add-on and its quantity, in a box that grows to hold them, footing to the total the guest signs.
“The team was always available, no matter the time. Guljar and his talented team developed three professional booking software systems and designed and developed more than four outstanding websites.”
NeoDimensional LLC builds reservation systems where the price on the page, the price in the quote and the price on the contract are the same number.
Book a free call →
