Case study · Party rentals

From a Facebook page to a real booking system.

Magnolia Slumber Party Rental delivers styled teepee sleepovers to customers' homes around Metropolis, Illinois. Before this project there was no website—just a Facebook page, some Marketplace listings, and a lot of messages asking whether a date was free.

The Magnolia Slumber Party Rental homepage: white canvas teepees with lavender tassel garlands and lanterns, under the headline We bring the whole party to your living room

The actual problem was the calendar

It is tempting to describe a business with no website as needing a website. That was not really the problem. The business was visible and busy on Facebook; photographs of finished setups were doing the marketing perfectly well.

The problem was that every enquiry began with a question only the owner could answer—is that Saturday free?—and ended with a conversation about themes, colours, and how many tents. That is a lot of messages to run a business through, and none of them were recorded anywhere that survived scrolling.

So the site was built around the calendar first and the brochure second. Everything else on it exists to get someone to a date they can actually check.

Research before writing a word

The project started as a documented research pass over everything already public: the business page, its posts, local group posts, and Marketplace listings. Each finding was written down with the source it came from.

The more useful half of that document was the list of things that could not be established. An old listing showed a price—from a different state, two years earlier. A phone number appeared on a graphic from the previous January and nowhere in the current contact details. A promotion had expired. Nothing was found about deposits, cancellation terms, delivery radius, or who launders the bedding.

All of it went on a list of questions for the owner rather than into draft copy. It is genuinely easy to write a confident FAQ from inference, and every sentence of it would have been a commitment the business had not agreed to make. Draft answers that had not been confirmed were removed before launch, including from the structured data—an unverified claim is still a claim when a search engine is the one reading it.

The booking system

Availability is public and live: visitors see which dates are open without contacting anyone. The data behind it is stored in a real database rather than a file redeployed with the site, which matters for an unglamorous reason—it means publishing a change to the website can never overwrite a live booking.

Submitting an enquiry does not reserve a date. That is a deliberate distinction, because auto-reserving on enquiry means an unanswered form can quietly block a Saturday. Enquiries arrive as pending, the owner confirms them, and only a confirmed booking takes the date.

  • Public availability calendar with a configurable lead time
  • Enquiries stored before any notification is sent, so a mail failure cannot lose one
  • Confirm, edit, cancel, and reschedule, each keeping its history
  • Date blocking with private reasons, which stay private
  • One confirmed party per date, enforced in the database rather than in the interface
  • Change history and a full export, so the data is portable

That last pair matters more than it sounds. Preventing double-booking in the browser stops an honest mistake; preventing it in the database stops two admin sessions, or two tabs, from confirming the same Saturday at the same time.

Build a Memory

The distinctive part of the site is a page where a customer picks a room, decides how the tents should sit, and taps dotted cut-outs to place stickers—tents, lanterns, garlands, trays, twinkle lights. The design they make is summarised and carried into the enquiry form, so the owner receives a picture of what the customer is imagining instead of a paragraph trying to describe it.

The Build a Memory page: theme and room selectors above a photograph of a living room overlaid with dotted cut-out shapes labelled tent, lights and garland
Build a Memory. It opens blank on purpose — an empty page with cut-outs explains what it is; a pre-filled one just looks like a picture.

Two decisions made it work. It is two taps, never a drag, so it works with one thumb on a phone—which is where a parent planning a birthday actually is. And the flat drawn stickers sit on photographs of real rooms rather than on illustrated ones. Matching the two registers was the first attempt and it looked like a cartoon; the clash between paper cut-out and photograph is what makes it read as a scrapbook.

There is also a constraint in it that has nothing to do with design. The tents are always white canvas on pine frames, because those are the tents the business owns. Colour comes from the blanket, the garland, and the pillows, and there are exactly five blankets. The artwork is not permitted to offer a customer something that cannot arrive.

Handing over the keys

The site runs in a hosting account for the business, not a folder inside mine. Over the days after launch, each piece of it moved across: the admin sign-in became the business's own email address, enquiry notifications were redirected to the owner's inbox, and the business address on the domain was verified and switched to forward to her.

Until that verification was complete, mail continued to reach me—and that state was written down as an open item rather than quietly left running. A handover that is ninety percent finished is a handover that is not finished, and the only way to keep track of the last ten percent is to name it.

The unglamorous half

The public forms are protected against bots, validated on the server rather than only in the browser, rate-limited, and checked for where the request came from. Admin pages refuse to be cached, are excluded from the sitemap, tell search engines not to index them, and sit behind a password whose hash is salted—with sessions that expire and can be revoked by changing it.

Public data is filtered so that the availability calendar exposes only whether a date is open. Names, email addresses, private notes, and the reasons a date is blocked never leave the admin. That was a fix, not a feature: an early version leaked private block reasons into the public calendar's tooltips, which is exactly the kind of thing an audit exists to catch before customers do.

Dates are calculated in the business's own timezone rather than the visitor's, which is the sort of detail nobody notices until someone in another state is shown the wrong day.

What this one demonstrates

Not every small business needs this much. Magnolia did, because the thing standing between it and more bookings was a calendar, and a calendar is software.

It is also an honest illustration of where the $1,800 starting price stops. A booking system, a live database, an admin with a full booking lifecycle, and a custom interactive page are all real additional work, and a build like this is scoped and quoted on its own. The starting price is for a normal small business website. Saying so is more useful than implying everything fits in one number.

Something similar?

If the bottleneck is a calendar, say so early.

Booking, scheduling, and availability work is quoted separately from a standard site, and the first conversation is the right place to find out whether you need it. Sometimes a well-placed phone number genuinely beats a booking system.

Start a conversation

Back to website design & development