A booking platform and marketing site for a car, Jeep and UTV rental company in Aruba. It quotes real prices for real dates, takes payment online and at the counter, and runs the business behind the scenes.
Booking Platform · Pricing Engine · Payments · Marketing Site
16Vehicle models bookable online, 24 units across cars, SUVs, vans, Jeeps and UTVs
8Seasons in the rate card, recurring every year by month and day
12Optional add-ons and protections, each priced per day or one-off
6Steps from picking dates to a paid, confirmed rental
5Pickup and return points, including the airport and cruise port
2,979Automated tests passing on the live release, 2026-10-07
01
One system runs the site, the booking and the counter.
Real Deal rents cars, Jeeps, vans and UTVs to visitors arriving by plane and cruise ship. Delivery to hotels, the airport and the cruise port is free. We built the booking platform the customer uses, the marketing site that feeds it, and the back office behind both. The two sites share one source of truth. The site reads its fleet and prices live from the booking system. Remove a vehicle in the admin and it leaves the website too.
01Step one asks for dates and locations before anything else. No price is shown yet, because none is knowable yet.02
The advertised price was not the real price.
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 means when the rate falls the longer you stay. Then every screen, quote and contract had to agree on it.
02Step two prices the whole fleet against those exact dates. The UTVs are grayed out here because a seven-day window is not a rental they offer. The rules are enforced, not just described.03
One pricing engine gets the last word.
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. 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. Otherwise the site quotes the visitor their own dates. The same engine drives the booking flow, the staff booking form and the customer quote.
03Step three names every optional charge. The panel keeps a running total: rental, tax and fee, deposit, and what is actually due now.04
From the pricing engine to the back office.
Seasonal pricing engine with duration ladders, priced per day against that day's own season and applied across the whole stay.
A marketing site that only advertises a rate it can honor, verified against short, long and peak-season windows before it is shown.
Six-step booking flow quoting live availability, add-ons, protections, taxes and a real total before the guest commits.
Online payments through Stripe Checkout (Mollie before it), deposit or full, plus cash and card at the desk, with one reconciled balance across all of them and refunds back to the card from the booking screen.
Secure payment links staff send by email or WhatsApp. They expire, close when the booking is cancelled, and cannot be paid twice.
Signed rental agreements generated as PDFs, itemizing every extra so nothing is charged without being named, with the signature captured at booking and again at handover.
Referral and partner links for hotels and tour desks, attributed automatically, with commission paid on the rental and never on tax.
An AI guest assistant that quotes exact totals with tax from the same pricing engine as checkout, in English and Spanish, and a reply composer that drafts answers for staff to review.
Back office for the counter: day board, calendar, fleet and maintenance, contracts, coupons and traffic fines, staff scheduling and work hours, finance ledger with export, roles and audit log.
Automations: a morning staff brief, unpaid online bookings holding their car as leads, and cancellation closing every open payment link.
04The marketing fleet page reads live from the booking system. A vehicle whose rate changes with trip length shows no day rate at all, because no single number would be true.05
6 phases, in the order they happened.
1
March 2026 · Pricing first
Seasons, duration ladders and tax modeled before a single screen was drawn, then the six-step booking flow and online payment on Mollie.
2
April 2026 · The counter
Back office for the people running the day, and the migration out of the previous vendor's system.
3
June to August 2026 · Depth
Fleet and maintenance, traffic fines, reports and staff; the owner's full rate card loaded; the new marketing site replacing WordPress.
4
September 2026 · Money
Stripe replaces Mollie with no downtime, payment links staff can send, one-time admin invites.
5
October 2026 · Trust
Refunds to card from the booking screen, the AI assistant quoting exact totals, the WhatsApp icon, cancellation and payment-link hardening.
6
Still running
Ongoing work against the live business: card refunds switching on, WhatsApp alerts to staff phones.
Application
Next.js 14 App Router, TypeScript, React Server Components
Data
PostgreSQL on Neon with Prisma 5, serializable transactions on anything that moves money
Payments
Stripe Checkout, refunds and webhooks (Mollie before it); cash and terminal card at the desk; reconciliation crons
AI
Google Gemini with function calling, totals only from the pricing engine
Documents
Server-generated rental agreement PDFs, signed and stored per booking
Delivery
Vercel, Cloudflare R2 for uploads, Gmail SMTP, Meta WhatsApp Cloud API
Tests
Vitest, 2,979 tests including a real-Postgres integration suite; 900+ commits on the live branch
06
The decisions that took longest to get right.
01
One engine, or three different truths
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. No screen can show a number the contract does not recognize.
02
A rate the site is allowed to advertise
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. It publishes a rate only when all three agree. When they disagree it says nothing and sends the visitor to quote their own dates. That is why some cars show a price and others deliberately do not.
03
Part-days round up, everywhere or nowhere
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. Otherwise two screens disagree about a real amount of money. It lives in one function that all of them call.
04
A card row stores what the terminal charged
A card payment at the desk carries a processing fee. Storing the rental amount instead of the amount charged left a phantom balance the size of the fee on every card booking. Card rows are stored gross, which is what the terminal took. The fee is separated for reporting instead of being quietly netted off.
05
Serializable where it counts
Two staff can edit the same booking at once, or a payment can land while someone edits it. Each then reads a balance and writes 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.
06
Every extra is named on the contract
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 itemizes the charge: the rental, each protection, each add-on and its quantity. The box grows to hold them and foots to the total the guest signs.
07
Seasons that recur by month and day
Rate cards change by season every year, and seasons stored per year rot. Seasons are stored as month-and-day ranges that repeat every year, with rental-length tiers and holiday overrides on top. The owner sets prices once, and every quote on the website, in checkout, in the admin and from the AI comes from one engine.
08
Switching payment providers with a flag, not a deploy
Moving from Mollie to Stripe had to happen with no downtime and no lost payments. The provider is a database column, so cutover and rollback are one update, and every payment's provider is read from its own id rather than a default. The old provider's payments still reconcile.
09
An AI that cannot invent a price
A language model quoting rental prices to guests is a liability. The assistant gets totals only from a tool that calls the same pricing engine as checkout, and a guard rejects any money figure that did not come from that tool. Quoted totals match checkout to the cent, in English and Spanish.
10
Unpaid bookings are leads, not junk
Abandoned online checkouts used to block cars or vanish. The owner's rule is that an unpaid online booking holds its car and stays as a lead for staff to follow up. Automatic cancels may only touch unconfirmed holds, and closing a booking closes every open payment link, so no car is double-booked and no guest is charged by surprise.
07
A price the business can stand behind.
Customers are quoted a price the business can stand behind. 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.
08
In the client's words.
“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.”
