Notes from building a membership platform for a medical society

Periopman, the Manchester Perioperative Medicine Society, brings together anaesthetists, surgeons, physicians, nurses, physiotherapists and residents from across the UK. I built the platform it runs on: membership and payments, event registration with member pricing, and talks that only members and delegates can open.

The case study covers what I built, with screenshots. These are the notes I'd give anyone building something similar.

The people who run it are the real users

Members visit a few times a year: to join, to register for an event, to watch a talk. The committee uses the platform all year, and they do it alongside full-time clinical jobs.

So the question behind every screen was: can a committee member do this in five minutes, between shifts, without asking anyone? If the answer was no, the feature wasn't done. A platform that delights members but needs a developer to change an event date isn't finished.

Keep the pricing rules in one place

There are three membership tiers: allied health professionals, residents, and consultants and SAS doctors. Events have member prices. Put those together and the rules multiply fast.

The lesson is simple: work the price out in one place, and make every page ask that place. If the event page, the registration form and the confirmation email each do their own maths, they will disagree one day, and it will be the day registration opens.

"Who can see this?" has more than one answer

After each meeting, the talks and media go online. But not to everyone. Members can see them, and so can the people who registered for that event, even if they aren't members.

Who can open this talk?

I'm a memberI registered for PeriopMan 26

Talk from PeriopMan 26

Locked. Join as a member, or register for the next event.

That's two different reasons to have access, and they change over time: memberships end, and new events add new delegates. Writing those rules down plainly, before writing any code, saved a lot of rework. Each piece of content knows who it's for, and each person's access follows from their membership and their registrations.

Never touch card details

The society takes membership fees and event payments online. It never stores a single card number. A payment processor handles the cards, and the platform only records that a payment happened.

For a small charity this isn't just safer, it's less work. Every card number you don't store is one you never have to protect, audit or explain.

Busy forms attract bots

Any form that sends email or creates an account gets found by bots, usually within days. Every form on the platform has bot protection, and the site asks for cookie consent before it loads anything that needs it.

Neither is exciting to build. Both are cheaper to add on day one than after the first wave of spam sign-ups.

Events fill up, so registration must hold up

Periopman's meetings are accredited by the Royal College of Anaesthetists and regularly fill up. That means most registrations arrive in a rush, right after a meeting opens.

Test the whole path before that moment: the event page, the price, the payment and the confirmation. Then do it again as a member, as a non-member and as a resident. The bugs that matter are the ones that only show up for one kind of person.

Where it is now

Periopman 26 ran on the platform in October 2026, and the 2027 resident meeting is next. The committee runs its membership, events and member content in one place.

If you run a society, a club or any membership organisation and want something like this, have a look at what I build or get in touch.