Chatter Snow

There was no infrastructure. A shared Gmail account and an Instagram profile were the entire operational stack — no domain, no organizational identity, no records, no system to track donated gear, coordinate volunteers, manage events, handle finances, or organize donations. Everything lived in DMs, threads, and individual people's heads, with no visibility for community members. Core issue: Chatter couldn't tell people "here's what we have available," and — more importantly for a group organizing toward nonprofit status — it couldn't tell anyone, including itself, what kind of impact it was actually having. A second problem surfaced once the system worked. Nothing about gear libraries, volunteer shifts, board minutes, or donation records is specific to snow sports, and other small organizations were solving the same problems with the same spreadsheets. But the code assumed exactly one organization: one tenant's domain was hardcoded as the platform's routing table, and every table held one org's rows with nothing separating them.

Chatter Snow is not a nonprofit yet; the group is actively organizing to become one. That framing drove the whole project: the infrastructure exists so the organization can measure and evidence its impact — gear distributed, members served, events run, money in and out — which is exactly what a nonprofit application and future funders will ask for. Add a volunteer team, effectively no budget, a growing inventory of donated ski and snowboard gear, and an active community that wanted to know what was available. Being both a board member and the technical lead meant seeing the operational need and the technical constraints firsthand. What started as one organization's tooling is now a multi-tenant platform, and Chatter Snow is its first tenant — which also meant drawing an ownership line through the repository between the generic platform and Chatter Snow's own brand, copy, and data before either had commercial value.

• Stand up real infrastructure — domain, email, identity, accounts — where none existed
• Create a centralized inventory system
• Enable the community to see available gear without a DM or an email
• Capture the operational data needed to evidence impact for nonprofit formation
• Serve more than one organization from one codebase, with each tenant's data isolated in the database rather than by application-layer care
• Give every tenant its own domain, branding, and public copy without a fork or a rebuild
• Make the system showable — a public demo anyone can walk through, with no real member data in it
• Keep it maintainable by volunteers — not over-engineered

• Effectively no budget — a pre-nonprofit group with no funding stream
• Starting from zero infrastructure, not migrating an existing system
• Volunteer-driven — the system couldn't be complex
• Real member, donor, and financial data in production: nothing from it could be copied into fixtures, tests, demos, or screenshots
• No super-admin: platform staff can't hold a standing bypass into a customer organization's data
• Multi-tenancy had to be retrofitted onto a live single-tenant system without an outage or a data migration people would notice
• No dedicated devops/infrastructure team

As board member and director, the operational workflows, community expectations, budget reality, and volunteer capabilities were already well understood. Key insight at the start: with nothing to migrate, the risk wasn't legacy — it was over-building. Buy the commodity pieces (domain, mail, hosting), build only what's specific to Chatter, start narrow with inventory, and design for expansion. The multi-tenant work started from a different question: where would a second organization's data leak? The answer was "anywhere a developer forgot," which is why isolation was pushed down into the schema — a policy predicate on every table, a composite foreign key on every relationship, and a query that reports any table missing either.

Core philosophy: minimal, maintainable, bought where possible, and generic by default. Two surfaces ship from one codebase — a public site and an operations portal — and both are now resolved per tenant. Next.js + TypeScript power both, backed by Supabase/PostgreSQL for inventory, events, volunteers, governance, and financials, with Zoho for organizational mail, Resend for transactional sending, Vercel for hosting, and Cloudflare for CDN and DNS. Multi-tenancy is a schema property, not an application convention: every tenant table carries a `tenant_id` with a default that resolves from the session, then the request host; every row-level security policy is scoped to the current tenant; every foreign key between two tenant tables is composite, so the database itself rejects a cross-tenant reference even from a service-role connection. The request `Host` is what decides which tenant a public page is for (matched against the tenant's custom domain, longest match wins), while the portal resolves the tenant from membership and never consults the host. Branding tokens and public site copy are per-tenant rows over platform defaults, so a new organization gets its own colors, logo, and page content without a fork. Deliberately not built: a custom CMS, a mobile app, and any super-admin role.

Functional and clear, focused on usability over visual polish — volunteers needed to understand the system quickly. A tenant's public site tells its community who it is and what gear is available; the ops portal is where the organization actually runs — inventory, volunteer coordination and shift signup, events and registrations, governance (board meetings, minutes, decisions, conflict-of-interest disclosures), donations, expenses, and reimbursements. Each organization edits its own copy, photos, and brand tokens from Administration rather than filing a ticket. Those same tokens render each tenant's own brand guide at /brand on its public site, so the reference a volunteer or a designer is handed is generated from what the product actually renders with — it cannot go stale, and nobody maintains it by hand. Access is role-based, with the permission matrix itself editable per tenant, so an organization decides what its own roles can do.

Phase zero was infrastructure that didn't exist: registering chattersnow.org, moving off the shared Gmail account to organizational email, and setting up DNS, hosting, and accounts. The initial build covered inventory management, the community-facing gear view, and basic volunteer coordination, then grew into the full ops portal — events, governance, donations and financial tracking, volunteer hours, and reporting. The multi-tenant conversion ran in phases against the live system: tenancy tables and membership first, then a `tenant_id` column and scoped policy on all 73 tenant tables plus 110 composite foreign keys, then host-based tenant resolution, then provisioning, per-tenant branding and site content, per-tenant data-retention rules, export and deletion, and finally a platform administration page so provisioning a tenant no longer needs a shell. The order was load-bearing: the first tenant's custom domain had to be set and verified before a second tenant went active, because a "sole active tenant" fallback was silently holding the public site together until then.

• Starting from zero — no domain, no org email, no records to migrate or learn from
• Requirement creep — once people saw the system working, everyone wanted new features
• Designing for volunteers — complex features had to stay simple to use
• Retrofitting tenancy onto a live database: a single forgotten policy or single-column foreign key is a silent cross-tenant leak, so the schema had to police itself
• Cross-tenant controls that were harmless with one tenant: data-retention purges and role administration were platform-wide, meaning any organization's admin could act on every organization's data
• Showing the system without exposing anyone: a demo needs an admin account that an anonymous stranger holds, which turns every remaining cross-tenant control into a public one
• Keeping the platform generic while it is also one specific organization's production system

A group that ran on a shared Gmail account and an Instagram profile now has a domain, organizational email, a public site, and an operations portal covering inventory, volunteers, events, governance, donations, and financials. The community can see available gear without sending a DM, and for the first time the organization is generating the operational record it needs to show its impact as it organizes toward nonprofit status. What was one organization's tooling is now a multi-tenant platform: a new organization can be provisioned with its own domain, branding, copy, roles, and retention rules, its data isolated at the database level, and it can export or delete everything it owns. Chatter Snow is tenant one, and a fully seeded demo of both surfaces is public at demo.rickiecruz.com. Specific impact figures are still TBD, pending more usage data.

• Infrastructure is the measurement — Chatter can't evidence its impact for nonprofit formation without a system that records what it does
• Start narrow, design wide — focusing on inventory first made launch possible, but the architecture allowed for expansion all the way to multi-tenancy
• Push isolation as low as it will go — a rule enforced by the database holds even when a developer, a script, or a future refactor forgets it, and a rule enforced by convention doesn't
• Every shortcut that was fine with one tenant becomes a vulnerability with two — a platform-wide purge job or a global admin control is invisible until the day it isn't
• Building a demo is a security exercise, not a marketing one — handing an anonymous visitor an admin account is the most honest audit of tenant isolation there is
• Draw the ownership line before the work has value — separating the generic platform from the organization's own material is cheap to do early and expensive to untangle later
• Get hands dirty — being on the board meant understanding real problems firsthand, an edge an outside consultant wouldn't have