Lucent Rental case: supercar site, 360° spin and built-in CRM
Lucent Rental is a bilingual supercar rental site for Dubai with a CRM, a shared inbox, payments after manual confirmation and a daily RTA fines check built into one system.
Lucent Rental is a supercar rental site for Dubai that I built in English and Russian. It has its own CRM, a shared inbox for chat channels, payment support that opens only after manual confirmation, and a daily check of RTA fines. The site is built and ready. The client has not connected it to a public domain yet, so this case covers how the system works and has no traffic or booking numbers.
If you run a rental company and want to know what a site can take off your managers' plates, this is a walkthrough of each part and what to ask for if you commission something similar. For the marketing side of car rental (channels, direct bookings, aggregators), the Savage Media journal has a separate car rental marketing playbook. This article stays on the build.
What a rental site has to handle
A supercar rental differs from a café or a clinic in three ways that shape the software:
- Every booking needs a human check. Someone confirms the car is free on those dates, looks at the client's documents and agrees on delivery.
- Money can arrive in several ways: UAE cards, foreign cards or crypto.
- The car keeps generating events after the client leaves: traffic fines, Salik tolls, damage. Each one has to be matched to the person who had the car that day.
A brochure site with a contact form covers none of this. The owner ends up with a site on one side and WhatsApp chats, a spreadsheet and a payment terminal on the other. In Lucent Rental, I built these parts into one system.
Catalogue and page structure
The site has four page types in both languages:
| Page type | Example of what it answers | URL pattern |
|---|---|---|
| Catalogue | "What can I rent?" | / and /ru/ |
| Car page | "What is this exact car, how much, is it free?" | /car/… |
| Brand page | "Which Lamborghinis do you have?" | /brand/… |
| Brand + location | "Rent a Lamborghini in a specific area" | /rent/{brand}/{location} |
The brand + location pages exist because people search with both words in the query. Hypothetical example: someone staying in Dubai Marina types "rent Lamborghini Dubai Marina". A page built for that pair has a better chance of matching the query than a general catalogue. The structure comes from the products: cars and brands first, then the places where clients want the car delivered. I wrote more about this logic in SEO site structure for a small business.
The database holds 61 cars, and 18 of them are marked available. A car can go to service or be sold. The owner switches it off and keeps its record, prices and photos in the system.
The 360° spin on one car
The car page supports a 360° spin, where the visitor drags to rotate the car. Right now one car has it: a Lamborghini Urus, built from 127 frames in WebP format. There is also an orbit video of the Urus.
How it works: the car is shot from fixed points in a full circle, each frame is exported, and the page swaps frames as the visitor drags. More frames give a smoother turn and a heavier page. WebP keeps the file size down.
A workable rule for spins on a rental fleet: shoot them for the cars that carry the brand, and give the rest of the fleet solid photo galleries. Every spin is a separate shoot. The car has to be washed, positioned and lit the same way all around. Promising "360° for every car" on the site before those shoots happen is a promise the page can't keep.
The CRM inside the site
Every request from the site becomes a lead with a status. The statuses follow the real life of a rental:
| Status | What it means for the staff |
|---|---|
| new | Request came in, nobody has replied |
| contacted | A manager has written or called |
| confirmed | Car, dates and delivery agreed |
| paid | Payment received |
| active | Car is with the client |
| completed | Car returned, booking closed |
There are two roles. The owner sees everything, including money. Staff work with leads, bookings and cars. With this split, a new manager can start work without seeing the full financial picture.
A status list lets the owner answer one question in ten seconds: how many requests are sitting in "new" right now? If that number grows, replies are slow, and the business loses clients before anyone talks to them.
One inbox for every channel
The code collects threads from four sources into one list. A manager replies from the admin panel without switching apps:
| Channel | How it enters the system | State on this project |
|---|---|---|
| Site chat | Built into the site | In the code |
Webhook /webhook/whatsapp |
In the code | |
| Telegram | Webhook /webhook/telegram |
In the code |
Webhook /webhook/instagram |
Supported in the code, Meta keys not connected |
In the Lucent Staff app, the same inbox shows each thread with a channel badge and an unread counter. The manager replies inside the thread, and the reply goes back to the channel the client wrote from.
Two questions to ask a developer who offers a shared inbox:
- Whose accounts are the channels connected to? The WhatsApp number, the Telegram bot and the Instagram page should belong to your company. If they sit on the contractor's accounts, you lose the history when you part ways.
- Is the thread linked to the lead? A reply in chat should be visible on the lead card. Otherwise the status in the CRM and the real conversation drift apart.
Payments only after a human says yes
The code supports three payment providers:
- Stripe for card payments in AED;
- YooKassa for Russian bank cards;
- NOWPayments for crypto.
Which of them go live depends on which merchant accounts the business opens and connects. The rule I built in: the client can pay only after a manager confirms the booking. The payment link appears at the "confirmed" step, never earlier.
The reason is practical. If a client pays for a car that turns out to be in service, you face a refund, fees and an annoyed person. A manual check first, then the payment link, keeps money and availability in sync. Before you switch on crypto or foreign card payments, ask your accountant or lawyer which methods your licence and bank allow. Scope and starting prices for builds like this are on the websites service page.
Daily RTA fines check
Once a day, the system checks traffic fines on the RTA service (ums.rta.ae) by the plate numbers of the fleet. A scheduled server job (the systemd timer lucent-fines.timer) runs the check. It is enabled, so nobody has to log in and look car by car.
Matching a fine to a client takes four steps:
- The job pulls fines for each plate in the fleet.
- Each fine has a date and a plate.
- The booking holds a car and a date range.
- Date plus car points to the client who had the car that day.
In the Lucent Staff app, the Fines screen shows each fine with the car, the plate and the client, marked paid or unpaid. When a manager adds a fine by hand, the app finds the booking by date.
Ask your contractor what happens when the check fails, for example when the RTA site does not respond. Someone should see that the daily run did not complete. If nobody notices, fines quietly pile up again. With manual weekly checks, some fines surface after the client has left the country. A daily automatic check shortens that gap.
Content for search and AI assistants
The site has 8 SEO guides in English and Russian. It also has the files that tell crawlers and AI assistants what is on the site:
sitemap.xmlwith every page;robots.txtwith crawl rules;llms.txtwith a short plain-text description of the business and its pages.
I explained how to write the last one in llms.txt: what it is and how to write one. On a two-language site, the English and Russian versions of each page also need correct hreflang tags. Without them, search engines may show a Russian speaker the English page.
None of this produces results while the site is off a public domain. Google can't index pages it can't reach.
The apps around the site
The site and CRM are the centre. Around them I built two iOS apps that work with the same data.
Lucent Staff is the staff app. It is in TestFlight and ready for release. It shows:
- today's deliveries and returns;
- leads with status filters;
- the shared inbox;
- the fleet on a dark map (the cars have no GPS trackers);
- fines;
- car prices and availability;
- client documents with expiry dates;
- a photo checklist at handover and return;
- a trip mode from "on my way" to "handed over".
The Money screen is visible to the owner only. Details are in the Lucent Staff case.
I also made the renter app. It has:
- a garage by category and brand;
- car pages with a 360° view and engine sound with haptics;
- booking with delivery to an address, hotel or airport;
- rental extension and documents;
- a map of delivery zones.
What a staff app changes in daily operations is covered in staff apps: what changes in venue operations, with this project and a lounge app as examples.
What not to do
Common mistakes in rental site projects. Some of them are steps still open on this one.
- Launching with placeholder content. On Lucent Rental, the hero photos are temporary images from Wikimedia Commons and the reviews on the landing page are placeholders. Both have to be replaced with the company's own photos and real reviews before the site goes public.
- Taking payment before confirmation. A booking form that charges a card at once looks convenient. It creates refunds when the car is unavailable.
- Putting channels on the contractor's accounts. Your WhatsApp number, bot and Meta page should be yours from day one.
- Promising features the content doesn't support. "360° for every car" with one spin shot breaks the promise on 60 of 61 cars.
- Leaving the domain step undefined. A finished site that nobody connects to a domain earns nothing. Agree in the contract who connects the domain and DNS, and by when. The clauses are in what to put in a website contract in Dubai.
- Reading fines by hand. If your staff checks RTA fines manually, they will miss some, and the company ends up paying them.
Checklist for a rental site brief
Use this list when you brief a developer for a rental site. Each line is a question with a yes or no answer.
- Does every car have its own page, and can I switch a car off without deleting it?
- Are there pages for brand and for brand plus location?
- Does every request land in a CRM with statuses I can count?
- Are there separate roles, so staff don't see revenue?
- Do site chat, WhatsApp and Telegram arrive in one inbox, connected to my accounts?
- Is the payment link sent only after a manager confirms the booking?
- Which payment providers are in the code, and which ones will I open accounts for?
- Are RTA fines checked automatically every day by plate, and matched to the booking by date?
- Will I see when the daily fines check fails?
- Are
sitemap.xml,robots.txtandllms.txtin place, with correct hreflang on both versions? - Are all photos and reviews mine, with no stock images or placeholders at launch?
- Who connects the domain, and on what date? The full build is on the Lucent Rental case page.
Questions and answers
How much does a rental website like this cost?
My websites start from AED 5,500 (Special offer). A build with a CRM, a shared inbox, payments and a fines check is a larger scope, so the price depends on which of these parts you need.
Are there booking or traffic results for Lucent Rental?
No. The site is built and ready, but the client has not connected it to a public domain yet. Without a live domain there is no search traffic and no booking data to report.
Can every car in the fleet get a 360° spin?
Yes, but each car needs its own shoot and its own frame sequence. Right now one car has a spin: a Lamborghini Urus with 127 frames.
Is Instagram Direct connected to the inbox?
Instagram is supported in the code, with its own webhook. It starts working once the business connects its own Meta account and keys.