Create a wedding website: which features do you really need?

A feature only earns its place when it answers a question that would otherwise reach you as a message. That is a harder test than it sounds, because every function looks useful in a demo, where nobody has eighty guests and four weeks left.

It also explains why comparison tables rarely settle anything. They count functions; a wedding is decided by which functions get used, by whom, and at which point in the eighteen months between the proposal and the party.

Almost every tool can show a timeline, directions and photos. Providers part company where a yes turns into a number you have to pass on — to the caterer, to the venue, to the seating plan. So this article sorts features by the moment they are needed, not by category.

Start with the guest rather than with the feature list. Almost everything a wedding page does belongs to one of two moments, and a function that belongs to neither is competing for attention with the ones that do.

The two are not equally weighted, either. One carries the reply, which you need; the other carries the logistics, which the guests need. Decisions that make the first look better at the cost of the second are the most reliable way to end up answering the phone.

Most guests open your page exactly twice. The first time, when the invitation arrives, they look for the date, the place and whether they may bring someone — and they either reply straight away or plan to do it later. The second time, in the week before the celebration, they look for the start time, directions, parking and the dress code. Anything falling into neither moment competes with the things that do.

The objection to that is fair: a page that is only a form feels like a registration desk. A personal opening is not decoration, then; it is the reason anybody scrolls down at all. It simply does not need half the page.

Feature scope and price are not two separate comparisons. What a package contains is mostly a set of quantities, and a quantity is what turns a feature from available into usable.

Which means the pricing page is worth reading as a feature page. Ask which functions live above the line you are paying at, and which of those you would still be using in the last week before the wedding.

What settles the choice is usually not the feature list but a quantity inside it: a package carries a fixed number of invitations and gallery slots — 100 or 150 invitations and 500 or 1000 photo slots depending on the package, both expandable. So the guest list comes first and the package second. Budget for 90 acceptances, invite 130 people, and you notice the difference exactly once: at the moment you send.

More important than the price is the line at which it starts. Creating, designing and previewing your page costs nothing here and asks for no payment details; invitations, replies, gallery and seating plan belong to the package. A free tier whose limit bites in the middle of your planning costs no money but a migration — and that always lands in the week with the least time to spare.

Three functions do the actual work: the reply form with your own questions, the personal invitation code, and an address short enough to print. Everything else on a feature list is built on top of those three or is decoration on the way past.

They also have to work in that order. A form nobody can reach is not a form, and a code that opens a page nobody can find on a card is not a code. The route from a printed invitation to a finished reply is the part a demo never shows you.

The reply form can be extended with your own questions: free text for allergies or overnight stays, choice lists for the menu or a shuttle, where every choice question needs at least one answer option. What matters is the order. Write your questions before the first invitation goes out. A question added later stays empty for everyone who has already replied — and those people you then chase one by one.

For guests without an email address the same route runs over the printed card: the personal code is on the invitation, the QR code is what gets scanned. If a reply never arrives, the invitation can be sent again — for the same guest only every 15 minutes, which mainly stops one stuck click from becoming five invitations. And if a code ends up in the wrong hands, you block that one code rather than rebuilding the whole page.

There is a privacy question hiding inside the feature list, and it is not the one about hosting. Ask it per function: does this collect anything about a guest, and who looks after that afterwards?

Most of the answer is reassuringly boring. A timeline, directions and a photograph of the two of you collect nothing at all. The functions that do collect something are, awkwardly, the ones that sound the most generous.

That yields a selection criterion no feature list carries: every extra function opens another collection somebody has to look after. A guestbook collects messages that get written into the real book on the night anyway. A song request form collects forty rows the band turns into ten titles. A gift list with money moving through it collects amounts and names — and is also the place where a provider earns without it appearing on the pricing page.

Cutting is not an end in itself, though. A countdown looks like decoration on a finished page, yet on a save-the-date page months ahead it is the only thing there is to show. And the multilingual guest view is either redundant or saves half the evening: as soon as two families speak different languages, it replaces the thread in which somebody translates the invitation. Keep whatever answers a question that would otherwise reach you as a message.

All of the above collapses into one exercise, and it is short enough to do in an evening: build a page, invite yourself, and reply. Everything a feature list cannot tell you shows up in those twenty minutes.

Those questions turn into a twenty-minute test you can actually run:

• Build the page without paying. Anyone who wants payment details before you have seen the page is reversing the order.
• Open it on the oldest phone in the family, not on yours.
• Add one custom question, invite yourself and reply.
• Change that reply. Does it overwrite the first one, or sit in the list twice?
• Export the guest list. What you cannot get out, you cannot hand to the caterer.

The second half starts after the first acceptance, and that is exactly where many demos stop: can the replies be turned into a seating plan and printed as a door plan, place cards and a caterer overview? Work through the cases nearly every guest list has, too: separated parents who want separate invitations, plus-ones confirmed only in the final month, and guests from abroad who need an answer about travel before they can accept.

Getting Married carries the three that matter — custom reply questions, a per-invitation code and your own address — in a single setup, with the seating plan and the gallery reading from the same replies.