Premium membership programs need first-party lead sourcing, segmented outreach, gated applications, code-validated enrollment, tier logic, and a campaign engine that runs first reaches, FOMO, scarcity, and window-closing flows across every cohort. None of that exists in a single off-the-shelf product. So I composed it: Klaviyo, Webflow, Prefinery, Airtable, Memberstack, and Stripe, stitched together with a thin layer of custom JS for the parts no tool handles natively. Same architecture under every program. The brand layer becomes a theme pass, not an architecture pass.
Off-the-shelf membership tools are either trivial or industrial. Neither one fits the sophisticated middle of premium brand programs. The space between is where the design problem lived, and the design solution had to be a system, not a product.
Memberstack, Whop, Patreon and the like solve a narrow case: open signups, a flat monthly plan, and a logged-in area. They are great at what they do. They do not handle invite-only acquisition, multi-tier plan logic with branded fulfillment per tier, referral attribution toward upgrades, or waitlists when a program is at capacity.
Brand-controlled gating, referral mechanics, tier routing, and the kind of branded UX that a premium spirits or hospitality program needs to feel like an invitation rather than a checkout.
Salesforce Loyalty Cloud, Talon.One, Annex Cloud: all capable, all designed for one giant client with a dedicated engineering team and a 6-to-12 month integration. None of that fits when a brand needs a launch in weeks and a fulfilled experience in months, with shared design and operations across a portfolio.
A way to launch a premium brand program in weeks, not months. A way to reuse the same operational backbone across 20+ programs without rebuilding it 20+ times. A way to keep the design system and the brand layer cleanly separated.
Premium membership programs need three things at once: a brand-distinct enrollment experience, real acquisition logic (invite-only, referral, tier, waitlist), and a path to scale across many brands without buying or building a new product per program. That combination did not exist in any single tool. The design contribution was figuring out how to compose it.
Five products, each doing what it does best, orchestrated into one acquisition pipeline. Same architecture under every program. The brand layer becomes a theme pass, not an architecture pass.
Each product owns a distinct moment in the journey, with Airtable as the underlying CRM and Klaviyo as the broadcast layer. Custom JavaScript handles the few jobs no tool does natively: invitation-code validation against the database, and Member ID generation with no-duplicate checks.
Each product owns a distinct moment, not a feature set. Airtable is the source of truth that every other product reads from or writes to. Klaviyo broadcasts across the entire lifecycle. Custom JavaScript covers the two jobs no tool does well: validating the invitation code at the enrollment gate, and generating Member IDs that are random (not sequential) and verified unique. The plumbing is the same every program. The brand and program-specific logic lives in configuration.
Most acquisition systems start cold. This one starts warm. Two upstream sources flow into Klaviyo before the campaign engine ever fires: brand-side opt-in lists, and AnyRoad's own first-party experiential attendance data. The combination is the moat. Most platforms can't pull from years of guest behavior on a brand's own properties.
Email captures from the brand's own marketing programs, prior loyalty enrollments, retail capture, event ticketing, and earlier brand-direct campaigns. Sometimes substantial; sometimes a starter set. Always cleaned and de-duplicated before scoring.
Pulled from the AnyRoad platform: every guest who's attended a brand-home tour, tasting, ticketed event, or activation. With dates, frequency, group size, and purchase behavior. I designed the segmentation and outreach layer specifically to use this data, since most third-party membership platforms wouldn't have access to it. The data shaped the architecture, not the other way around.
Both sources land in Klaviyo. From there: clean, score, and segment. Frequency of visits. Distance from the venue. Purchase behavior. Engagement with prior brand emails. Plus categorical filters (members of related brand programs, demographic indicators, opt-in date). The output is a tiered cohort: priority, qualified, nurture. Each segment receives a different campaign track.
Two practical effects of this. First, conversion rates on outreach run materially higher because the cohort is already pre-qualified for affinity. Second, the brand-side conversation about who to invite stops being a guess and starts being an analysis. The same scoring logic carries forward across every program in the LTL ecosystem; only the source data changes per brand.
I split the funnel into two sites with different goals. The application site is where qualified candidates apply for membership; final value props, pricing, and fulfillment depth all stay behind a second door. The application site's job is to communicate enough premium signal to make the apply-button feel like an opportunity, while leaving room for the enrollment site to land the bigger reveal once the candidate is invited in.
The page is themed per program: hero, brand voice, a handful of teaser benefits, a Prefinery application form embedded inline. The form captures member-side info, opt-in for marketing, and the referral-name field if the candidate was referred by a current member.
Applications flow into Airtable in real time. Klaviyo re-segments the application pool by quality signals (lead source, AnyRoad attendance density, referral status) and routes each segment into different downstream campaign tracks.
One quiet feature here: referral capture as supplementary acquisition. Current members who refer new applicants are tracked at the application step, with a referrer-name field that links back to the existing member's Airtable record. During acquisition periods, successful referrers receive promo offers (extra event entries, member-only allocations, fulfillment perks). The system is curated-list-first; referrals augment, they don't replace.
Another: waitlist as a first-class state. When a program is at capacity, applications still flow through the same Prefinery form. Prefinery's application timestamp acts as the waitlist queue. Waitlisted applicants are notified, then nurtured by Klaviyo with periodic updates as their status changes. The wait becomes part of the program experience, not exclusion from it.
I treated Klaviyo as the spine of the system rather than just the email tool. Across both sites, across the entire acquisition window, every cohort moves through a sequenced campaign. First reaches. Reminders. FOMO touches. Scarcity messaging. Window-closing pushes. Plus general program updates and re-engagement for cooler segments. The campaigns differ per cohort because the segmentation differs.
Initial outreach to a freshly-segmented cohort. Tight subject line, a clear ask: apply for membership. Branded HTML built once and themed per program.
Members who opened but didn't apply. Members who didn't open. Members who clicked but bailed at the form. Each behavior triggers a different reminder track with different timing and tone.
Mid-window social proof: applications received, members already enrolled, recent member events, brand momentum. Designed to convert the watching-but-not-applying segment.
Late-window: capacity warnings, member-only allocations going fast, founders-tier seats counting down. Triggered only when capacity signals justify it; over-using scarcity flattens its effect.
Final push before the application window closes. Different copy for cohort that's already interacted vs. cohort that hasn't, with timing tuned to the program's typical engagement curve.
Outside acquisition windows or for capped programs: keep the candidate engaged. Brand updates, event recaps, milestone touches. The wait stays warm.
Cross-channel. The Klaviyo orchestration is the spine, but the campaign also extends into social media (program-specific creative, organic and paid) and on-site upsell at the brand-home venues themselves. A guest finishing a tour at a brand-home walks past program signage, gets a takeaway card, and lands in the same outreach cohort the next morning.
Once a candidate is accepted, an invitation email arrives carrying a unique code. The code unlocks the enrollment site: full value props, complete tier breakdown, real pricing, fulfillment detail. Everything that was held back on the application site is here. Code-gating turns the application moment into part of the brand promise: the invitation is the experience, not the hurdle.
Klaviyo fires the acceptance email when the application is approved. The voice is the program's; the code is unique to the recipient and tied to their member record in Airtable. The CTA is a one-click route to the enrollment site, with the code passed in the URL so the member never has to type it.
The enrollment site is built later than the application site, after the brand has firmed up final value props, pricing, and fulfillment commitments. It reveals everything: tier breakdown, member benefits, allocations, events, fulfillment cadence. But every visitor lands on a code-entry gate first.
The validation runs through a thin layer of custom JavaScript: the entered code is checked against the Airtable database of issued invitation codes. Valid code grants access to the enrollment flow. Invalid code returns a clear error without losing the candidate. The code-gating logic isn't something Memberstack or Webflow does natively, so it lives as custom code that I wrote and maintain.
Once the code validates, the integrated Memberstack component handles account creation: name, email, password. Standard signup, no second confirmation step. Behind the scenes, custom code runs at the moment of account creation: a unique Member ID is auto-generated, validated against the existing Member ID list in Airtable to guarantee no duplicates, and attached to the new account's Memberstack metadata.
Member IDs are random, not sequential. A sequential ID would expose membership volume to anyone who could observe two IDs across time. Random IDs (validated for uniqueness) keep the count opaque. Small decision, real security implication.
Memberstack's redirect flows take the new account directly to the plan picker. Tiers are presented with the program's branded hierarchy. Payment cadence (annual, semi-annual where the program offers it) sits on the same screen. The candidate commits to their plan and prepares for payment in one motion.
Plan selection redirects to a Stripe-integrated payment screen. Subscription state is created in Stripe; Memberstack metadata picks up the tier; Airtable's member record updates with subscription status. The brand-specific tier mapping triggers downstream fulfillment paths (welcome kit, allocation, event access) automatically.
After successful payment, the candidate lands on a final-details screen: shipping address, phone, SMS-update opt-ins, dietary or preference fields where the program collects them. Anything the brand needs to operationalize membership, captured at the moment the relationship begins. Klaviyo then fires the welcome flow, and the candidate is now a member.
The same six-product pipeline ships every program in the LTL ecosystem. The brand layer, the tone, the price, the tier shape, the segmentation criteria, and the fulfillment all change. The plumbing does not. Three programs across spirits, sports, and hospitality below.
Three programs, three completely different brand expressions, three different audience strategies. One acquisition system underneath. Adding the next program is a configuration exercise, not an architecture exercise: Webflow themes, Klaviyo segments, Prefinery rules, Airtable schema, Memberstack plan keys, Stripe products. The plumbing is settled.
The most consequential decisions on this project were about what not to build. A few of the larger ones below.
The instinct on a project of this scope is to spec a custom platform. Real engineering, an internal admin, a database schema designed exactly for the use case. That path would have taken at least six months before the first program could launch.
Composition. Six products, each chosen for the moment they handle best, plus a thin layer of custom JS for the few jobs no tool handles natively. The first program shipped in a few weeks, the next eighteen all on the same plumbing. That decision is the spine of the project.
A single site simplifies the URL story and reduces the surface area we maintain. It also forces the brand to commit to final value props, pricing, and fulfillment detail before the application window opens.
Two sites: an early application site (sneak-peek of the program, branded shell) and a later enrollment site (full reveal, code-gated entry). The brand can run application campaigns while still finalizing tier structure and offerings. Candidates feel chosen rather than sold to. The application becomes the first signal of premium, not a checkout in disguise.
Sequential IDs (00001, 00002, 00003) are easy to generate, easy to read, easy to debug. Most early-stage systems start that way.
Random Member IDs, validated against the existing Airtable list to guarantee uniqueness. Sequential IDs leak total membership volume to anyone who can observe two IDs across time, which matters for premium programs whose value depends partly on perceived scarcity. Random IDs keep the count opaque without making operations harder. Small decision, real security implication, irreversible once the first program launches.
Memberstack supports gated content. With creative configuration, the invitation-code mechanism could have lived inside Memberstack's plan and access logic.
A thin layer of custom JS validates the invitation code against the Airtable database before Memberstack ever sees the candidate. Two reasons. First, codes can be rotated, revoked, or invalidated without touching member records. Second, the validation is plain JS calling Airtable's API, which is portable. If we ever swap Memberstack for another auth provider, the gate doesn't have to be rebuilt. Composition over lock-in.
Open the door, let anyone apply, run server-side rules to qualify. Easier marketing funnel, lower friction at the top, more raw applications.
Curated outreach. The qualifying happens upstream, in Klaviyo, on the lead lists themselves. Brand opt-ins plus AnyRoad attendance data scored and segmented before any campaign fires. Conversion rates run materially higher because the cohort is already pre-qualified, and the application step actually means something. The brand's invitation isn't extended to everyone; it's extended to the right set of people on purpose.
The change I felt most as a designer was where my time went. On the first program, most of my hours went to figuring out the architecture: which product owns which moment, what data passes between them, where the seams are. By the third program, those questions were settled. The work shifted upstream: brand expression, tier shape, fulfillment rhythm, campaign tone. Each program got more design thinking because less of the budget was being burned on infrastructure decisions.
The hardest part wasn't the integration. Webhooks and metadata mappings are fiddly but solvable. The hardest part was deciding which product owned which moment, and holding that line as new requirements came up. Every quarter someone would ask "could Memberstack handle the waitlist?" or "could we generate the Member IDs in Memberstack itself?" The answer was almost always no. Each product is best at one thing; once you let a product creep into another's territory, the seams stop being clean and the next program takes longer to ship.
The second lesson was about brand surface area. The six-product stack felt invisible to the candidate because we put the design budget exactly where the candidate looks: the application page, the invitation email, the enrollment landing, the welcome handoff. The plumbing got engineered judgment, the surfaces got design judgment. That separation kept the system feeling premium even though most of the technology underneath is off-the-shelf SaaS.
The third lesson was about data as a starting condition. Every acquisition project I've worked on since starts with the same question: what data does this company already have, and how can I design around it? When we had years of first-party attendance data to work from, the segmentation layer became the spine of the system. On a project without that data, the architecture would have looked completely different. Designing on top of an existing data advantage taught me to read for the data shape before sketching the funnel.
The fourth lesson was about scope. I could have stopped at Heaven Hill and called it a deployment. I didn't. I treated the first program as a template and the second as a stress test. By the third, the patterns were obvious and the launch curve flattened. The reusability wasn't an accident; it was the design.
What I'd push next: fewer products. The six-product stack works, but every additional integration is a seam that can drift. A natural consolidation candidate is folding Prefinery's referral and waitlist mechanics into Memberstack's metadata, and folding parts of Airtable's CRM logic into Memberstack's member fields. That would take the architecture from six products to four (Klaviyo, Webflow, Memberstack, Stripe), with a thinner custom-code layer for the gating and ID generation. The composition pattern stays. The surface area shrinks.