Wedding website

A wedding website earns its place by answering once, and in public, the questions you would otherwise answer forty times by text message: where, when, what time the ceremony, what time the reception, where to park, whether there is a bus back into town. So the first decision is not a design decision. It is working out what the site has to do — collect replies, hold the guest list, carry the addresses — because that settles everything after it.

Start with the replies. RSVP is the one function with a deadline attached: caterers and venues want a final number weeks before the day, and every guest who has not answered turns into a phone call for somebody. Ask only for what you will actually use — name, meal choice, dietary requirements, whether a child is coming — and stop there. Every extra field costs you replies and leaves you holding data you now have to look after.

The web address comes up earlier than most couples expect, because it gets printed. Once the save-the-dates are in the post the URL cannot change, so decide before the stationery order whether you want a subdomain or a domain of your own. The real test is being able to read it aloud across a dinner table without spelling it twice.

That leaves the private half. The venue address, phone numbers, photographs of your family — none of it needs to be findable through a search engine. An invite code or a password puts the practical pages behind a door while the front page stays public, and under UK and Irish data protection rules that is also the simplest way to keep guest details from travelling further than they should. Photos last: agree who may upload, who may download, and what happens to the gallery once the honeymoon is over.