Websites · Custom website and reservation system
Planirent - Car Rental Website & Reservation Flow
Custom car rental website and reservation system with card payments, availability logic, and practical operator workflows.
Overview
Planirent is a car rental business. We built the website and the reservation system behind it: vehicle listings, availability by date, card payments, confirmation pages, a reservation management area, an operator approval step, and refund handling.
Business context
Car rental is an operations business wearing a website. The public site has to make a vehicle look worth renting and make booking it feel safe, while the operator behind it needs to keep control over which reservations are accepted, when a vehicle is genuinely available, and what happens when a customer cancels. Those two audiences want different things from the same system.
The challenge
The workflow did not fit any available rental plugin. Availability is date-range based rather than per-day, deposits are taken at reservation time, every reservation needs operator approval before it is confirmed rather than being auto-accepted, and cancellations require refund handling that respects what was already taken. Each of those exists in isolation in some plugin; the combination did not, and working around it would have meant a plugin fighting three others.
UX and interface
The public side leads with the vehicles, because that is what the decision is made on. The date selection is placed before the catalogue rather than after it, so customers see availability-filtered results rather than discovering at checkout that their dates do not work. Each step of the reservation flow shows what has been chosen and what is still needed, and the total - including the deposit - is visible before the payment step rather than revealed at it.
Development
Built in React and TypeScript. The reservation logic is written rather than configured: range-based availability checks, pending holds, state transitions between pending, confirmed, cancelled and refunded, and the rules governing which transitions are allowed. Payments go through Stripe, with the payment state and the reservation state kept consistent so a successful charge cannot leave an unconfirmed reservation behind.
Architecture and integrations
The reservation record is the single source of truth for a booking's state, with payment and refund events attached to it rather than tracked separately. Stripe handles card data, so the application never stores it. Transactional email is triggered by state transitions rather than by the interface, so a confirmation cannot be sent for a reservation that did not actually change state.
Performance and search
The public marketing and vehicle pages are server-rendered and crawlable; the reservation management area and operator tooling sit behind authentication and are excluded from indexing and from the sitemap. Vehicle pages carry unique titles, descriptions and headings rather than a generated pattern, and imagery is sized and served responsively.
What was delivered
A working rental platform in which a visitor can check availability, reserve a vehicle and pay, and the operator can approve, manage and refund reservations from one place - replacing a workflow that no combination of plugins covered. We have no verified post-launch conversion or revenue figures to publish.
Scope
- Public website and vehicle catalogue
- Date-based availability and pricing logic
- Reservation flow from search through to confirmation
- Card payment integration
- Confirmation pages and transactional email
- Reservation management area for customers
- Operator approval workflow and refund handling
Strategy and key decisions
Model availability before designing screens
Availability is the core of the product, so it was modelled first: a reservation occupies a range, ranges cannot overlap for a vehicle, and pending reservations hold their range while awaiting approval. Designing the interface before settling that would have produced screens that could not express the real rules.
Keep the operator in the loop by design
Auto-confirmation is simpler to build and wrong for this business. A reservation is created as pending, holds the dates, and becomes confirmed only when the operator approves it. The customer-facing copy states this plainly, so nobody arrives expecting a car that was never accepted.
Design the failure states first
Declined cards, dates that became unavailable during checkout, cancellations and refunds are where reservation systems actually break. Those states were designed as part of the flow rather than handled by a generic error page.
Remove friction without removing control
The customer path is short - dates, vehicle, details, payment, confirmation - with no account required to reserve. The control the business needs lives on the operator side rather than being pushed into the customer flow as extra steps.
This write-up describes work delivered and capabilities built. It does not report traffic, conversion or revenue figures, because we do not have verified post-launch measurements to publish.
Have a similar project?
Tell us what you want to build and we will come back with a clear, honest plan.