// case study
My Place Cigar Lounge
Private members-only cigar lounge with a custom marketing site, member portal, and admin dashboard
- Year
- 2026
- Role
- Solo developer — public marketing site, authenticated member area, and full admin panel.
- Status
- Live
my-place-lounge.com
// about this project
What it does and how I built it
A members-only experience for Rochester's cigar enthusiasts. The public marketing site showcases 24/7 access, personal humidor storage, and events. The authenticated members area powers dashboards, cigar profiles, a member directory, and RSVPs. The admin panel lets ownership manage members, events, invites, and announcements.
My role: Solo developer — public marketing site, authenticated member area, and full admin panel.
// decisions
One Next.js app for marketing + member portal + admin
Could have shipped a separate static marketing site and a separate authenticated app. Instead one codebase serves public marketing routes, the auth-gated member dashboard, and the owner admin panel — shared components, shared design tokens, one deploy pipeline. Saves the ongoing tax of cross-app drift; trade-off is slightly larger first-load JS on public pages.
Supabase + Auth.js instead of rolling auth
Members-only feature was the riskiest scope. Supabase + Auth.js give me battle-tested auth, RBAC, and a Postgres I can query in 5 minutes, instead of a 2-week detour into JWT and session management. The cost is a $25/month line item; the saved week paid for years of that subscription.
Three-tier RBAC (owner / admin / member) enforced server-side
Easy approach: client-side role checks. Correct approach: middleware that gates every API route and page on role, with the client UI as a UX hint only. Worth the extra hour up front because the alternative — finding out a member can hit an admin endpoint — is a production incident.
Test discipline: Vitest + Playwright + RLS policy tests
Vitest covers auth helpers, RBAC role-resolution, and content schemas. Playwright runs an E2E pass on the public marketing site plus an authenticated flow for the member dashboard and admin actions. Supabase Row-Level-Security policies have a dedicated test suite that spawns service-role and user-role clients to assert every policy actually denies what it claims to. Lighthouse mobile ≥ 95 + axe-core zero-violation block the merge on every PR.
// highlights
- Public marketing site with dark elegant theme — black, gold, serif typography
- Authenticated member area — dashboard, cigar profile, directory, messaging
- Full admin panel — members, events, RSVPs, invites, announcements
- Role-based access control with owner / admin / member tiers
// what I’d do differently
I built the member/owner role model iteratively, layering access rules on as features landed, and wrote the RLS test suite after the policies existed. Today I would write the full access matrix — who can read and write what, per role — before the first database migration, with count-based policy tests from day one. Authorization is the one layer where "add it as you go" quietly accumulates risk.
Stack
- Next.js 16
- TypeScript
- Tailwind CSS 4
- Supabase (auth + Postgres)
- Stripe
- Sanity
- Vercel
AI Tools
- Claude Code
- Multi-tool AI workflow
Built with AI as a force multiplier — scaffolding, research, automation, and code review all flow through these tools in my daily loop.
// gallery
Screenshots
Toggle between desktop and mobile views.
Desktop · 1440 × 900
// let’s build
Want something like this?
I design, build, and ship production systems end-to-end — and I’m looking for a remote full-time role where I can do it with a team.