Building the Rampant Club Members Portal In-House
The Setup
The Rampant Club is a 99-member private whisky society in District 1, Ho Chi Minh City. Small by design. The membership cap isn't a marketing position, it's the operating model. Everything about how the club functions, from the membership planning to the events calendar to the way a dram gets reserved for a specific guest on a specific Tuesday, only works because the number stays small and the relationships stay close.
When the question came up of how to run the digital side of that, the default answer was what every consultant would have given: buy a club management platform. There are a handful of them aimed at private clubs, all of them designed for properties with two thousand members and three restaurants. They cost money, they require training, and they bring with them a particular kind of generic-feeling guest experience that the Rampant Club had been built specifically to avoid.
We talked the client out of it and built the portal ourselves.
Why Building Beat Buying
The case for off-the-shelf software in private members clubs rests on three assumptions that didn't hold here.
The first is that the feature set is too complex to build. It isn't, not at this scale. A club with 99 members needs maybe a dozen genuinely important screens: member directory, event RSVP, bottle reservation against personal cellar holdings, billing, guest invitation, house-account ledger, a few admin views. The complexity in the platforms isn't in those features. It's in the surrounding infrastructure designed for a much larger operation.
The second assumption is that custom builds don't scale. True if you're planning to grow to a thousand members. Not true if the entire commercial model is predicated on never doing that. The Rampant Club was capped at 99 from day one. The portal would never need to handle more than 99 members. Building for that constraint produced a faster, simpler, more elegant product than any platform aimed at a more flexible market could have offered.
The third assumption is that off-the-shelf is cheaper. Once we ran the maths it wasn't, even before counting the implementation and training costs the licence fee never quite includes. The build paid back inside fourteen months versus the cheapest credible alternative, and from year two it ran on infrastructure costs alone.
What We Built
The stack was deliberately conservative. Vercel for hosting. Supabase for the database and auth. Resend for transactional email. GitHub for everything else. Boring choices on purpose, because the goal wasn't to build something architecturally clever, it was to build something that would still be running quietly in three years without a maintenance contract.
The product itself was scoped tight. Members logged in with a password link and saw their own dashboard, which showed their personal whisky holdings, the upcoming events list with one-tap RSVP, and their current house account balance. Staff had a separate admin view for cellar management, notice board, menus, event creation, billing and guest list approval. Nothing else. No social feed. No messaging. No member-to-member features that nobody had asked for and that would have created moderation problems we didn't want.
The thing it did do, that no off-the-shelf platform would have done, was speak the club's language. The terminology, the membership tiers, the way a single-cask bottle was tracked from arrival through bottling allocation to the specific member's holding, all of it modelled on how the club actually thought about its own operation rather than how a generic platform's data model wanted to think about it. That alignment is invisible when it works. It's the bit that makes the digital experience feel like part of the club rather than something bolted onto it.
What It Did for the Operation
The operational lift was meaningful in two specific places.
Event RSVPs stopped going through WhatsApp or Zalo, which had been the previous system and which had been quietly costing the managers about four hours a week in chasing, reconciling and updating spreadsheets. The portal handled it in zero. That time went back into the floor and customer gifting and service programmes, which is where you want a private club manager's time to be.
The whisky holdings atlas view solved a problem the club had been working around since opening. Members with bottles in storage previously had to ask the manager what they had left, which felt slightly embarrassing for the member and was operationally annoying for the manager. The portal made it self-service, and the side effect was a measurable increase in bottle consumption. Members who could see their holdings drank from them more often.
What We Didn't Build
A mobile app. The portal was mobile-web from day one, which on a tight user base of 99 known people is functionally identical to an app and a fraction of the cost. A native app would have meant App Store review cycles, two codebases, push notification infrastructure and a permanent maintenance burden in exchange for almost nothing the members would actually feel.
Analytics beyond the basics. With 99 users the manager already knows who's engaged and who isn't. The Analytics and member interview process was covered in a different project earlier on, which gave the client the necessary tools to build the website to the members’ specifications.
The Lesson Worth Noting
The reflex in any small-scale operation is to assume that the right software exists somewhere off the shelf and the job is to find it and configure it. Sometimes that's right. For a 99-member club with a deliberately bespoke operating model, it wasn't the optimum direction. The right tool was the one shaped exactly to the work, and at this scale, building that tool was cheaper, faster and produced a better product than buying one ever would have done. They now only pay a tiny domain annual cost.
