Velora Luxe
Designer dress hire, Auckland and nationwide Built new on the rental engine
Hire is the hardest thing to sell online, because what the customer is buying is a set of dates. Every size of every gown keeps its own calendar, the item comes back, gets cleaned and goes out again, and the whole thing hangs on one question a shopping cart was never built to ask. We made that question the product page.
A hire house, and the calendar inside it.
Screenshots taken from the live site, not from a mockup. The brand, the photography and the voice are the client's. The booking engine underneath is ours.
The homepage opens on the occasion rather than the product, because nobody hires a gown in the abstract. Underneath it, the site is a full store with a cart, a checkout and card payment.
The booking control on a gown. Choose a size, choose four or eight days, then pick the day of the event. Days that are already taken in that size cannot be picked, and the arrival and return dates are worked out and stated before anyone commits to anything.
The same homepage at 390 pixels wide. The calendar works the same way on this screen, down to the size of the tap target on each day.
Ecommerce assumes the item never comes back.
Velora Luxe hires designer gowns, bags and jewellery for weddings, galas, graduations and everything in between: four or eight days, couriered both ways, with private fittings at the boutique for anyone who wants one. That is a straightforward business to explain and an awkward one to put online. Every ordinary ecommerce platform is built on a stock count that goes down when something sells and stays down. A hire house sells the same gown many times over, and what it is actually selling each time is a window of days.
That changes almost everything about a product page. Availability has to be kept for each size separately, since one booking of a size eight says nothing about the size twelve hanging next to it. Days have to be held between bookings for the courier and the dry cleaner. The customer thinks in terms of the day of the event, not the day the parcel arrives, so the site has to do that arithmetic instead of asking them to. And none of it can break the ordinary half of the shop, because accessories and optional damage cover are bought outright and ride to the checkout in the same cart.
A store where the calendar is the product page.
Pick the day of the event, not the logistics
The question on the page is when the dress is being worn. From that one answer and the hire length, the platform works out the day it has to ship, the day it has to come back, and whether that whole span is free in the chosen size. The customer sees the outcome in a sentence before they reserve anything: it arrives on this day, it goes back by that one.
A calendar for every size
Each size of each gown keeps its own ledger of days. Booking one never greys out another, and because a hired item is not consumed, a stock count is deliberately not the mechanism: the days decide. Buffer days sit between one booking and the next so the courier and the dry cleaner are not being asked to do the impossible.
Reserved, then paid, then confirmed
Choosing dates puts a hold on them while the customer finishes checking out, so two people cannot pay for the same gown on the same weekend. If the hold runs out the dates go back on sale and the stale checkout is refused rather than quietly overbooking the rail. Payment is what turns the hold into a confirmed booking written into the ledger.
Hire and purchase in one basket
Accessories are bought, gowns are hired, and optional damage cover is chosen at the checkout, all in the same order and the same payment. Each hire line carries its own dates through the cart, the payment and the order record, so the shop's order screen shows what is going out, in what size, and when it is due back.
What working with us actually looked like.
The interesting part of a project like this is not the feature list. It is what happens between the request and the thing being live, including the times we said we thought a request was a mistake.
We handed them a working booking flow
The situation. Online hire is hard to picture from a description, and a shop cannot sensibly give feedback on a paragraph about calendars. Nobody had asked us for a demo.
What we did. We built one on their own site, with a sample gown and sample pricing, and sent them the link: choose a size, choose four or eight days, pick your event date, watch the taken days grey out and the arrival and return dates appear, reserve. Everything after that was a conversation about a real thing rather than an idea.
The extra step we talked them out of
The ask. They wanted their optional damage cover to be its own page between the cart and the checkout, with a detailed design to match, so that every customer had to make the choice deliberately.
What we did. We said what we thought first: every additional step in a checkout costs completed orders, and a page between cart and payment is a place to abandon. Then we built the same content into the checkout itself, three cover levels with a clear way to decline and a terms confirmation before payment. Same decision, same disclosure, one page fewer.
A listing card drawn from a reference image
The ask. They sent a picture of how they wanted the gowns to appear in a list: designer, name, the price with the hire length beside it, the size range, and a row of colour dots. Our card showed a photograph, a name and a price.
What we did. Rather than bolt the extra rows onto one storefront, we made them part of the platform's product card and put each row behind a switch, so this store turned them on and every other store looked exactly as it did the day before. The colour dots appear the moment the shop fills in each gown's colour, with no further code.
One of ours is running here.
Every app on the platform is included on every site at no monthly fee. This shop runs the one that turns a store into a hire business.
Rental Booking
FREE
Date based reservations on any product: hire lengths with their own pricing, a calendar that knows what is already booked in that exact size, buffer days between bookings, a hold while the customer pays, and the dates carried into the order so the shop knows what is out and when it is due back.
Renting out something that comes back?
Gowns, suits, cameras, marquees, tools, trailers: the moment an item is hired rather than sold, an ordinary online store stops being able to describe what you do, and the usual answer is a booking widget bolted to the side of a shop that does not know about it. Here the calendar, the cart, the payment and the order are one system. Tell us what you hire out, how long a typical booking runs and how you handle turnaround. WebForger is invite only, so the first step is a short application rather than a signup form.