Background & Context

The client is a solo-founded private membership organization preparing to launch a vetted, closed community platform. Unlike an open social network, membership is gated behind a real application: age verification, background and identity checks, references, and interviews. That vetting model is both the product's core value and its central engineering constraint, because it means the platform holds legally and personally sensitive records from the first interaction.

The organization operates in a category that mainstream infrastructure treats as a liability. General-purpose hosts (GoDaddy- and Namecheap-style registrars) name adult-adjacent content as prohibited in their acceptable-use policies. Payment processors are stricter still: the default processor for a launch of this scope may pass underwriting today and restrict or terminate the account tomorrow. Building as if any single vendor is permanent was not an option.

The founder is also the sole operator, which shaped every build decision toward one codebase, one deployable app, and admin tooling that lets one or two people run vetting, payments, moderation, and member support without a five-screen scavenger hunt.

Problem Statement

The Question: How do you build a payments-enabled, data-sensitive community platform on modern infrastructure when the two things you most depend on (your payment processor and your host) can revoke you at any time, and when the data you hold is more sensitive than a typical SaaS app ever touches?

The Problem: The organization needed vetting, a member portal, and paid event ticketing, but off-the-shelf event and membership tools either prohibit the category outright, route discretion-sensitive data through third parties, or lock payments to a single processor. There was no product to buy; it had to be built.

The Challenge: Three constraints ran through every decision. First, payment resilience: losing the ability to take payment at all is the real failure mode, not just losing one product line. Second, least-privilege data access: identity and health-verification documents can be readable only by the narrow vetting role, and every access has to be auditable. Third, member safety and discretion: block/report, anti-stalking directory limits, and no-staff-read messaging are safety requirements, not nice-to-haves, in a community where a leak is more damaging than in most consumer apps.

Methodology / Approach

I built a single Next.js (App Router) application rather than splitting the public marketing site and the gated member portal into separate deployments. Route groups plus session-and-role middleware handle the public/member/admin split cleanly inside one codebase, which is the right tradeoff for a solo operator: separate deployments would buy cache and security isolation at the cost of maintenance overhead one person can't absorb.

The stack:

• Next.js (App Router) for public pages, the gated member portal, and role-gated /admin tooling, all in one app.
• Supabase (Postgres, Auth, Storage, Realtime) for authentication, application and vetting records, events, content, file storage, and real-time messaging, with row-level security as the primary authorization boundary rather than app-layer checks alone.
• Stripe as the default processor, integrated behind a processor-agnostic payment abstraction so an adult-friendly processor (CCBill/Epoch) can take over any or all transaction types without rewriting the checkout or ledger code.

The guiding principle was that the sensitive parts of the system (who can read a health document, whether a spoofed webhook can fake a payment, whether a revoked member can still walk into an event) had to be enforced at the data and protocol layer, not just in UI conditionals.

Analysis and Findings

Before building the member portal, I studied the dominant open platform in this space and deliberately borrowed its proven content primitives (structured member profiles, private messaging, albums, block/report) while rejecting the infrastructure it built to manage anonymity and discovery at open-platform scale. A vetted, closed community doesn't have the same problems, so it shouldn't inherit the same complexity. That analysis produced concrete decisions:

• Directory search is deliberately restricted. The member-facing directory does not allow filtering by demographic characteristics. Being vetted doesn't remove the risk of one member using search to target another, so the same anti-stalking restriction that open platforms adopt for anonymity is retained here for safety. The admin side stays unrestricted for legitimate moderation.
• The payment layer is the single biggest resilience risk. The failure to guard against isn't "one product line gets cut off," it's "we can't charge anyone at all." That reframing is why failover is designed to be automatic and processor-agnostic rather than a manual cutover a founder triggers mid-incident.
• The most sensitive data must never sit behind app-layer checks alone. Identity and health-verification documents are stored as access-restricted Storage objects under RLS scoped to the vetting-reviewer role, with every access captured in an audit log.

Solutions and Implementation

Vetting and admin core. A multi-reviewer application queue (claim, recommend, approve, deny) with a full audit log, application-time references that gate approval, and a revocation model that is distinct from a simple denial: a revoked identity is blocked from silently reapplying under different contact details until an admin explicitly lifts the lockout. Alongside it, a safety/incident log with immutable incident facts, a KPI reporting view (approval rate, referral share, revocation rate, safety-escalation rate, all-time and last-30-days), a referral tracker with an append-only credit ledger, and an individual-recipient broadcast tool that never exposes a shared recipient list, to protect member discretion.

Paid ticketing with capacity and a charge-on-promotion waitlist. This was the most interesting engineering work. Events support per-category pricing and capacity (the community tracks attendance by relationship category, shown as remaining slots, never exact headcounts), an optional RSVP cutoff, and Stripe Elements checkout with referral-credit redemption. The waitlist is the standout: for a paid category, a waitlisted member is charged only at the moment they are promoted into a confirmed slot, never before. A confirmed paid RSVP is final sale by default, with a one-step manual admin refund for exceptional cases, deliberately chosen over automatic self-service refunds. Couple RSVPs either link an existing member (who must confirm before it counts toward capacity) or open a guest request for admin approval.

Payment integrity. Checkout runs through a dedicated route; a Stripe webhook handler verifies signatures server-side and is idempotent, so a spoofed or duplicated event can't fake a payment or double-charge. Every transaction is written to a ledger through the processor-agnostic abstraction, so a combined cross-processor reconciliation view slots in once failover is live.

Member portal. Structured member profiles and a directory (with the search restriction above), one-way follows and mutual friend requests, private 1:1 and group messaging over Supabase Realtime with attachments and no staff read access, and a member blog that flows private → submit-for-review → public through the same moderation queue used for applications. A member-facing block/report tool feeds the admin safety log directly: blocking severs and hides relationships mutually; reporting opens a review status visible only to the reporter.

Security posture. RLS-enforced member/reviewer/admin roles with least-privilege document access, rehype-sanitize on every Markdown field (stored-XSS is a real vector once members write content others read), verified payment webhooks, CSRF-protected state-changing admin actions, rate limiting on auth and application endpoints, and an audit log that also captures security-relevant events like unusual access to verification documents.

Conclusion and Lessons Learned

The vetting core, member portal, and paid-ticketing system are all shipped and functional ahead of the organization's planned launch. The platform can run its whole vetting-to-ticketing lifecycle today, and it is built so that the two vendor dependencies most likely to fail (the payment processor and, by extension, the host) can be swapped without a rewrite.

What worked well was treating the hardest constraints as architecture rather than features. Making the payment layer processor-agnostic from the first line meant "what if Stripe drops us" was never a rebuild; pushing authorization into row-level security meant a UI bug can't leak a health document; making the ticketing webhook idempotent from the start meant payment integrity didn't depend on getting retries perfect. The waitlist that charges on promotion is a small idea with an outsized payoff: it removes the refund-churn and the hold-a-charge-you-might-cancel problem in one design decision.

Some things are deliberately deferred rather than half-built: cross-processor reconciliation and the actual second-processor integration wait on account provisioning; photo/video albums and health-document uploads are correctly gated behind a content-safety scanning decision before any user-uploaded media goes live. The broader lesson generalizes past this one client: when the risky dependency is external and can revoke you, the resilient move is to build the seam before you need it, and when the data is sensitive, enforce the boundary at the layer a bug can't cross.

Quotes and Testimonials

[Omitted: no attributable client quote is included, consistent with the confidentiality of this engagement.]