Diane Party Rentals
From manual quotes and disconnected payments to online bookings, with an operating platform for the work after checkout.
Download PDFAt a glance
$5,032.66
Stripe gross volume · April–September 8, 2026
15
New Stripe customers · same reporting period
$4,881.62
Stripe net volume · same reporting period
Where it started
Diane Party Rentals is a family-operated rental company in Frederick, Maryland. They reached out to me in March 2026 with a site on Wix’s free plan. Bookings and quotes were handled manually. Payments came in as cash, Cash App, Venmo or Zelle.
I started with the brand and assets, then designed and built the website, quote and payment flow, and the admin behind each booking. The work runs from how someone first encounters Diane to what the crew sees when it arrives at their event.
By September 8, the Stripe dashboard showed $5,032.66 in gross volume and 15 new customers. The immediate change was a booking with its payment, balance and receipt in one place. The operational workflows below extend that record into delivery and sourcing; I do not yet have measured turnaround or labor savings for them.
From a quote to a paid booking
The old payment methods worked, but the booking lived elsewhere. Someone still had to connect the money to the event and keep track of what remained to be paid. Adding a checkout meant bringing those pieces together.
The customer reviews the equipment and dates, accepts the quote and follows the payment link. The payment then belongs to that booking, alongside its balance and receipt. The team has a record to return to when the customer calls.
Stripe handles the online payment. By September 8, the dashboard records $5,032.66 in gross volume, $4,881.62 in net volume and 15 new customers across April–September 2026.
Giving Diane an identity
I began with the wordmark, monogram and reusable assets in Paper. The same identity carries through the catalog, quotes, customer emails and delivery documents.
Choosing what to rent
Most customers arrive with an occasion in mind. A birthday, a wedding, a school event. I wanted the site to help them work out what they needed: which chairs, how many tables, whether delivery and setup were available. Equipment photographs do much of that work.
The location pages carry the same catalog into the areas DPR serves, with local delivery information. Schools and other institutions have their own path too. A purchase order comes with different questions from a birthday booking.
Getting everything there
Payment processing has production evidence. The agent-assisted coordination shown here is the operating workflow I have been building and testing, rather than a measured business outcome. Its job is to prepare decisions and follow approved work through without treating a sent request as a confirmed commitment.
With the customer’s booking and payment in one place, I followed the work into fulfillment. There is still a truck to load, a crew to assign and a customer waiting at the other end. A late pickup can affect the next delivery. A damaged table can leave tomorrow’s booking short.
That is where I spent most of the time on the admin. It opens on the work that needs a decision: a delivery conflict, a supplier reservation, a purchase order with the wrong quantity. Open an item and you are in the booking or request it belongs to. Work already under way and completed actions sit below it.
The workflow starts checks from business events: a changed booking triggers readiness checks; a shortage opens sourcing; an unanswered request remains due for follow-up. Chat is available against the record, but it is not the trigger for routine operational work.
Moving a delivery
Two customers need equipment at the same time. One has a fixed loading window; the other may be able to take delivery the evening before. That is a common sort of problem here, and solving it involves more than dragging a calendar entry.
The platform checks stock, crew and the vehicle, then prepares another window. The operator sees what changes, what stays put and the message the customer will receive. Approving sends the request. The appointment moves after the customer agrees and capacity is checked again.
I kept those steps visible. A sent message is not an agreement. If someone changes the booking while a reply is coming back, the old approval needs another look. The record holds the conversation and the decision together, so the next person can pick it up.
Finding thirty more chairs
DPR also brings in equipment from other suppliers. For larger setups, it hires temporary help. Both involve finding someone, checking availability, agreeing on terms and making sure they actually confirm.
For equipment, the agent starts with approved suppliers and researches alternatives when needed. It collects quantities, prices and collection terms in one request. A chair listed on a website stays unverified until the supplier confirms it is available for the date.
Availability requests and reminders can go out under the team’s policy. Committing money needs approval. If a supplier does not answer, the request stays open and the follow-up has a deadline. It does not disappear into an email thread.
At the venue
The office view is only half of the handoff. The person unloading needs the venue, item count and setup instructions on a phone. I designed the mobile flow around that moment: check what arrived, take a photograph, record the condition and capture who accepted it.
Pickup and inspection continue the record. A missing chair or a damaged table needs evidence before it becomes a stock adjustment or a customer charge. The agent can gather the relevant records and flag the discrepancy; the crew still has to count and inspect the equipment.
Keeping the context
A booking accumulates things: a quote, a payment, a purchase order, delivery photographs, a note about which gate to use. Those details need to travel with the work. The agent can find them, and the person checking its answer can open the source.
I use Eve to coordinate the agents and work that waits for a reply or approval. Cloudflare Workers runs the application logic around the operational records. I keep prices, stock and permissions in that layer so every action passes the same checks, whether it starts with a person or an agent.
I used shadcn/ui for the interface, giving me established components to build on and more time for the behavior around them. Details open in sheets beside the current record, and a question stays with the work it concerns. Closing a sheet does not cancel the task. Coming back to it does not start the same action again.
The point is to give the team less to chase. A customer knows when to expect the delivery. A supplier has confirmed the extra chairs. The crew can see what needs loading. The useful work is in those details.
The design and engineering decisions are closely tied here. A delivery approval needs to show the customer’s message, but it also needs to notice if the booking changed while that message was being reviewed. I work through both sides of that interaction: what a person needs to understand, and what the system has to guarantee.
If you’re hiring a software engineer or have an operational problem like this, I’d be happy to talk.
What I would measure next
The next useful measures are quote turnaround, last-minute delivery changes, missing items at handoff, and how often the team has to chase a supplier or customer. I would measure those against the old workflow before claiming time saved. Successful automation here means a confirmed delivery and the right equipment on the truck.