Cooc
A Central London members club that had to become a membership system after launch — registration, approval, billing and a wallet pass — designed and wired on WordPress at Palm PR.
2025
- Client
- Cooc, with The Mandrake
- Type
- Members-club site and membership system
- Stack
- Figma, WordPress, Divi, MemberPress, New User Approve, Zapier, Passcreator
- Team
- Palm PR; Beth Lucas on front-end development
When the brief changed
The brand site had to become a membership operation in weeks.
Cooc is a private members club in Central London, under The Mandrake. The first brief was a brand site. Weeks after that site went live, the club needed people to apply, be approved, pay, and carry a pass on their phone.
Initial proposal
A brand-focused WordPress site: look, tone and a public presence for the club. Proposal agreed May 2024. UX, branding and graphic design in July. Front-end and back-end in August. Original site live December 2024.
Discovery
In February 2025 the request changed. They needed registration, payment collection and digital Apple and Android Wallet passes for door access, without waiting on a native app. A custom membership product — the kind of thing a house like Soho House runs as its own app — would have been the longer fit. The timeline did not allow it. WordPress, with plugins that already knew members, billing and passes, was the path that could ship in weeks.
Product response
I designed the membership journey in Figma — options, application, approval, email, wallet pass — and the pass itself. Beth Lucas was the front-end developer. I built the WordPress membership wiring: a Divi registration form into MemberPress, New User Approve holding applications, MemberPress plans and recurring billing, Passcreator for the wallet pass, Zapier for the welcome mail and admin notice. I designed that journey inside the WordPress constraint the timeline required.
The membership loop.
A club site, then the membership loop that had to hang off it.
Built at Palm PR. Brand site through December 2024. Membership platform requested February 2025 and live March 2025. Screens here are the Figma work, the journey wireframe, the comparison that decided the stack, and the pass I designed. Mario Brown on the card is test data.
Problem
The club’s tone is surreal and maximal — photography, costume, collage. A default Divi layout would have read as a brochure. The registration area still had to feel like joining a house, not filling a plugin form.
Solution
SangBlue Sans for display. Palette: burnt orange, light pink, salmon red, dark green. Logo as four overlapping crescents. Mood references layered like the venue. High-fidelity frames in Figma covered heroes, memberships, account and club pages before they were built in WordPress.
Before
- A brand site scoped as look and feel
- Plugin forms that look like plugin forms
After
- Type, colour and logo specified in Figma
- Registration treated as an initiation, not a contact block
- Live site at cooc.london
Problem
Membership is not a page. Someone has to pick a tier, apply, wait, pay, and then have something to show at the door. If that path only lived in the developers’ heads, WordPress would assemble the plugins in the wrong order.
Solution
A wireframe flow: Membership Options on the landing page, three tiers, the application form, internal approve or deny, a confirmation mail with a pass link, then the card stored in Apple or Android Wallet. Figma also explored account, merchandise and room layouts that WordPress would not fully become.
Before
- A live brand site with no join loop
- Door access as a later problem
After
- Mapped path from options to wallet
- Approval as a named step, not an inbox
- Room-booking frames left as exploration, not a shipped module
Problem
Anyone can submit a form. A members club cannot let that submission become a paying member on its own. The office had to see applications and approve or refuse them before billing started.
Solution
Members register through a custom-designed Divi form. MemberPress captures the submission. New User Approve holds it in review. An admin signs the person off, or they do not join.
Before
- A public site with no application gate
- No named hold between form and member
After
- Divi form as the application
- MemberPress as the member record
- New User Approve as the hold
Problem
Tiers existed in the design — including an Over 33 member type on the pass. Without a plan on the member record, approval is only a yes, and the door still has nothing to check against.
Solution
Approved members are auto-enrolled on their MemberPress plan — standard, inner circle, or otherwise — with recurring billing on that plan. The pass later reads the member type from that record.
Before
- Tiers as marketing copy
- Payment as a later conversation
After
- Plan assignment on approval
- Recurring billing in MemberPress
- Member type available to the pass
Problem
A native app would have been the membership card. They needed something people already carry: Apple Wallet and Google Wallet. The pass still had to look like Cooc, not like a default Passcreator template.
Solution
A portrait pass: Cooc mark, member type, name, status, email, QR and member ID. Passcreator generates the wallet file. Zapier sends the download link in the welcome mail. Mario Brown / mario.brown@test.co.uk on the still is test data, not a member.
Before
- No digital ID for the door
- A default wallet pass if we had skipped the design
After
- Designed Cooc pass in Figma
- Passcreator as the issuer
- QR and member ID on the card
Problem
Once the club is a membership product, the next questions are who came, who they can message, what they did, and whether bookings in SevenRooms show up in the same place. WordPress with these plugins does not give those surfaces.
Solution
I compared a custom app with WordPress on flexibility, UX, scale, performance, speed, cost, CMS and security, and shipped WordPress because speed and the existing CMS won the February window. The gaps stay listed. They are not filled with empty laptop frames.
Before
- A membership loop that can launch
- No attendance, in-platform chat, member analytics, or SevenRooms API
After
- Trade-offs written down rather than hidden
- Custom app named as the longer product, not this release
04 / Deep dives
What the March deadline forced us to decide
The brief looked like WordPress. The work that mattered was the pivot, the stack choice, and a join path that ended in a pass people could hold.
From a live brand site to a membership system in weeks
Problem
The original site went live in December 2024 as a brand presence. In February 2025 the club asked for registration, payment and Apple Wallet passes. A native app or an ERP-style dashboard would have been the scale answer. They needed something that could be live in March.
Contribution
I already had the UX, branding and graphic design from July, and the site in WordPress from August. The February work was a front-end redesign plus MemberPress, Zapier and Passcreator — joining tools the CMS could already run, on a journey I had drawn.
Constraints
- Original website live December 2024.
- Membership platform requested February 2025 and live March 2025.
- Beth Lucas on front-end development.
- Do not wait on a custom app.
- Door access had to be a wallet pass, not a new download from an app store.
Keep WordPress, add the membership loop
The brand site was already the public face. Rebuilding it as Laravel would have missed March. MemberPress, New User Approve, Zapier and Passcreator sat on the stack that was already live.
Design the pass
Passcreator issues the file. The layout — mark, member type, identity, QR, ID — is the Figma card. Test member on the still is Mario Brown.
Treat approval as operations
New User Approve holds the application. Zapier tells admins. Billing starts after the yes.
May 2024 to March 2025. Brand site live in December. Membership platform requested in February and live in March.
Outcome
Membership platform live March 2025 at cooc.london. Brand site and membership loop on the same WordPress install.
05 / Design to code
Where the design had to survive the plugins
Figma held the brand, the pages and the pass. WordPress, Divi and MemberPress were how those frames became a live club site. Zapier and Passcreator were how approval became a mail and a wallet file. I designed the system and wired it; Beth Lucas built front-end. The stack is the one that could ship in March.
Hold applications in the CMS, not in an inbox
Divi writes to MemberPress. New User Approve is the gate. Billing does not start on submit.
Let Zapier carry the pass link
Welcome mail with a download link, and a notice to admins on approval. That is operations visibility without a custom notification service.
Design the wallet card as a product surface
Passcreator issues it. The Cooc layout is mine. Test member on the still is labelled as test data.
Figma to shipped
- Figma
- WordPress
- Divi
- MemberPress
- New User Approve
- Zapier
- Passcreator
- Apple Wallet
- Google Wallet
06 / Outcome and status
Where the product stands
The brand site launched in December 2024. Three months later, COOC had moved from a promotional website into an operational membership service, covering application, approval, billing and digital member access. The launch used WordPress and existing services rather than the custom club app originally explored, allowing the team to meet the March 2025 opening window.
Evidence
- Shipped: brand site and membership journey covering application, approval, billing and digital pass.
- Observed in 2026: COOC continues to operate an online membership service, including active membership tiers, applications, payments and digital-pass support.
- Design evidence: Figma journey covering membership options, application, approval, welcome communication and wallet pass.
- Launch architecture: WordPress with Divi, MemberPress, New User Approve, Zapier and Passcreator, chosen to meet the launch window rather than delaying for a custom application.
Evidence boundary
Post-launch analytics and member behaviour were not available to me after handover, so I do not attribute conversion, retention or operational-efficiency figures to the work.
Product boundary
The shipped service covered acquisition and member access, not full club operations. Attendance, messaging, member history, analytics and a direct SevenRooms integration remained outside the launch scope. If those became operational priorities, I would reassess the service architecture rather than continuing to extend the plugin stack.
Reflection
The constraint was not something I would remove in hindsight. With the same February-to-March deadline, I would still ship WordPress. It gave COOC the membership capability it needed without waiting for a larger custom product. The important distinction is knowing where that solution should stop scaling.