Wedding List Manager

Wedding platforms have an awkward shape: the people using them are not the people paying for them. Most resolve that by charging couples for the tools they need, or by selling their details on to suppliers who then chase them. Both work commercially, and both cost the couple something they never agreed to.

Wedding List Manager was built to resolve it the other way round. Everything a couple needs in order to plan — guest list, seating plan, invitations and RSVPs, budget, photo albums, a wedding website — is free, and stays free. The revenue comes entirely from the supplier side: venues, photographers, florists and planners buy tokens and spend them to be discovered by couples who have opted in to hearing from them.

That constraint set the scope. The UK only, so the compliance surface is one jurisdiction rather than twenty. A single account model, because a photographer planning their own wedding is one person and not two logins. And a standing rule that a couple's trust is never the thing traded away — which went on to decide considerably more of the architecture than anyone expected at the outset.

One account, many capabilities. Roles are granted after registration rather than picked at sign-up, so the same login can plan your wedding, help with a friend's, and run a business. Permissions are capability-based the whole way down — 31 policies and 198 form requests — and the supplier portal layers its own per-business team roles on top, so an owner can hand a gallery to an assistant without handing over the enquiries.

Three front doors, each with one gate. Couples and suppliers sign in. Guests never do: the guest portal runs entirely on invitation tokens, so somebody can reply, record an allergy and upload photographs without an account existing anywhere. Each door has a single authenticator rather than checks scattered across controllers, which is the thing that makes them auditable at all.

Money is append-only. Every token movement — purchase, hold, spend, release, refund — is an immutable ledger row written through one row-locked service that computes the running balance and refuses any debit that would take it below zero. Corrections are new offsetting rows, never edits to old ones. Financial records are kept for seven years regardless of what happens to the account.

The most useful decision was one not to build. The gift registry and honeymoon fund take no money at all: couples add their own payment link, guests pay them directly, and every screen says plainly that a claim is a pledge rather than a payment. Receiving and remitting guests' money is a regulated payment service under the Payment Services Regulations 2017, and it would have brought chargebacks against couples after the honeymoon, refunds on cancelled weddings, and identity checks in the middle of planning — in exchange for revenue that competitors already give away for nothing.

Quality is enforced rather than intended. Every user-facing change ships with its migration and foreign keys, a policy, a form request, feature tests covering the authorisation boundary, and a changelog entry written for couples rather than for developers. Around 7,500 tests run against the suite. Deployment is Docker images built by GitHub Actions on merge.

It is live, and it has been shipping continuously since March 2026 — 1,860 commits, 725 routes, 505 views, 108 kinds of notification. Couples manage guest lists and drag-and-drop seating plans, send invitations that work without the guest ever creating an account, build a wedding website out of a block editor, track a budget against real supplier quotes, and share photo galleries with moderation they control. Suppliers get a public profile, a bookings diary that publishes as a subscribable calendar feed, enquiry handling, and a token balance they spend on reaching couples who asked to be reached.

Some of the better work is in the parts nobody sees. Planning nudges are sent by a lifecycle engine an admin can edit: a visual AND/OR rule builder over a vetted field catalogue, compiling to checked query fragments rather than raw SQL, holding itself to one automated email per person per week. Uploads are virus-scanned before they are stored. No supplier is publicly visible until a person has reviewed and signed them off — email verification alone is never enough.

Recent effort has gone into hardening rather than features. Systematic multi-pass audits across authorisation, data integrity, race conditions, timezone handling, queue reliability and injection, with each finding fixed under a regression test and a note recording what it actually cost a real person. That has closed, among others, a reflected XSS on a public page, a marketplace filter that silently ignored what was typed into it, and an email preferences page that quietly unsubscribed couples from everything the moment they changed one setting.

It is early days commercially. The platform is in production with real weddings running on it, and the marketplace side is nearer its beginning than its end.

View on: https://weddinglistmanager.co.uk