Lamp & Rose
Multi-tenant platform for Nurse Honor Guard chapters: public sites, member portals, and admin tools that scale without mixing data.
The Problem
Nurse Honor Guard chapters are run by retired nurses. They spent decades in healthcare, not tech, and they're managing volunteer organizations with paper sign-up sheets, email threads, cash donations, and spreadsheets on someone's personal laptop. The chapter leaders I talked to tracked member dues in one spreadsheet, ceremony availability in another, and training certifications in a third, all while fielding emails about who could cover a service next Tuesday.
What I Built
Lamp & Rose gives each chapter its own space (a subdomain or custom domain) with public pages, a member portal, and admin tools. One platform serves many chapters with strict data isolation.
The admin console consolidates everything chapter leaders were juggling separately:
Member management: Full roster with contact info, dues status, training certifications, and ceremony availability. Filter by who's trained, who's current on dues, who's available on a given date. Nobody has to cross-reference three spreadsheets to answer a simple question.
Ceremony coordination: Schedule ceremonies, request volunteers, track RSVPs, record attendance. Members see upcoming ceremonies in their portal and can indicate availability directly. Admins get a clear picture of who's signed up without chasing emails.
Training & credentials: Track who's completed what training and when certifications expire. Overdue credentials get flagged automatically, and leadership can pull compliance reports when they need them.
Communications: Announcements, event reminders, dues notices. Templated messages pull in member data so no one's copy-pasting names into emails one at a time.
Payments
I integrated Stripe Connect so donations and dues route directly to each chapter's account. The platform takes no cut.
Public donations: Visitors donate from the public site with embedded checkout instead of being bounced to a third-party page. Attribution ties to the chapter at the moment of payment.
Member dues: Members pay through the portal. The system tracks payment history, sends renewal reminders, and flags overdue accounts. Admins see who's current at a glance without maintaining a separate ledger.
There's no manual reconciliation and no spreadsheet handoff at the end of the month.
The Hard Part
Multi-tenancy with payments. Public chapter sites, subdomains, private member portals, chapter-level payments, and a platform management layer all rest on the same tenant boundary, and a donation landing in the wrong chapter's account is the one failure the platform cannot have. So every request carries explicit tenant context rather than guessing or falling back to a default, and if context is missing the system fails closed. That rule runs through routing, permissions, data access, and observability, and it was designed in from the start rather than bolted on later.
The other challenge was the domain itself. I knew nothing about this industry when I started, so I had to learn the workflows, vocabulary, and edge cases before I could model the system correctly.
Tech Stack
Frontend: Next.js App Router, React, TypeScript, Tailwind, shadcn/ui.
Backend: Supabase for auth, Postgres, and storage.
Payments: Stripe Connect for multi-tenant attribution.
Quality: Zod for validation, Playwright for E2E, Vitest for unit/integration, Redis/Upstash for caching and rate limiting.
How It Came Together
This is the first thing I built that's actually used outside work. I started with an anchor chapter, one group of chapter leaders whose first requirements list was a photo of notes on a napkin. We worked closely throughout the build: they tested continuously as I shipped, and I adjusted based on what they found.
It was also the first project where what I needed most from AI was domain knowledge rather than code. I'm not involved with Nurse Honor Guard chapters, so I used it to research how they operate: their ceremonies, training requirements, membership structures, the vocabulary they use. That research shaped the domain model and helped me ask the chapter leaders better questions when I validated against the real thing.
The architecture moved from single-tenant to multi-tenant once it was clear the anchor chapter's pain points weren't unique: every chapter juggles the same spreadsheets, email chains, and manual payment tracking. Build once, and any chapter can spin up its own instance with full data isolation.