Nobody Books a Bathroom From a Stock Photo

Like Ravenscroft, this is a referral business: decades of work, most of it repeat customers and word of mouth. And like Ravenscroft, the referral is only the first half of the transaction. The name gets passed across a fence or a kitchen table, and then the homeowner does what everyone does with a name now, which is search it. Until this project, that search found nothing.

What the search needs to find is different here, though. A patient checking an anaesthetist wants credentials. A homeowner checking a plumber before committing to a five-figure bathroom wants photographs, and specifically proof that the work is real, recent, and to the standard they are picturing. So the site had to be the portfolio that turns up thirty seconds after the recommendation does.

That decided almost everything else. The homepage isn't a brochure with a gallery at the bottom, it's a gallery with just enough words around it.

The business arrived with their Facebook page, which meant real bathrooms in real houses: inconsistent lighting, mixed resolutions, and a lot more honesty than any stock photo. I kept them. A stock image of a bathroom tells a customer nothing except that you know where to buy stock images.

The gallery is built to be handled rather than glanced at, so images zoom on mobile. That is where the deciding happens, usually on a sofa with a phone. It's a Payload collection rather than markup, so when a job finishes the owner uploads the photo and hits publish. The newest bathroom on the site should always be the last one he tiled.

Every plumber in Hampshire has the same generic blue, white and grey website. I wanted to go upmarket instead, so the palette is emerald and gold. The work being sold is luxury bathroom installation, and the site should look closer to the bathrooms than to the van. The palette does the positioning on its own, before anyone has read a word.

Design took longer than the code, across two Figma rounds with the owner. I think that was the right way round for a site like this: the design is doing the arguing, and the code's job is to stay out of its way.

The stack is the same as Ravenscroft's: Payload behind Next.js, deployed to AWS with OpenNext, and the same shallow content model philosophy. Services, gallery and testimonials are each a collection the owner edits against a live preview and publishes when he's ready, so nothing goes live by accident.

The engineering problem specific to this one is weight. A page that is mostly photographs is a page that is mostly bytes, and the customers are on phones. So the page loads in the order a visitor reads it: the bathtub and the logo first, the rest of the gallery after the paint is dry. Nobody is waiting on a photo they haven't scrolled to yet.

Since handover the gallery and testimonials have been his to run, and he runs them. He hasn't needed me since. Not one call, not one 'how do I'. That was the design goal of the admin panel, and it's the only metric on this page.

Which is the same lesson as the last build, really. The site earns its keep the same way he does: show the work, and be there when someone looks.