Church Connect

Deploy once, serve any church from its own subdomain — one build, many tenants

All projects  ·  About Matt

Source is public on GitHub; deployable to any host. Built with AI-assisted development — designed and directed by me, implemented with AI pair programming.


Description


What it does: An embeddable church engagement tool that a single deployment can serve to any number of churches. Each church (a "tenant") gets its own branding, accounts, and data — all changeable at runtime — resolved from the subdomain it's loaded on, so connect.gracechurch.org and riverside.connect.app are the same build with different identities.

Configurable per church: Features live in one registry — Events, Announcements, Sermons, Prayer, Leadership, Small Groups, and Meals. A church turns features on by listing their keys and can rename any of them (e.g. "Meals" → "Potlucks"). Nothing is hard-coded to one congregation.

How it was built: React 19 + Vite. The active tenant is resolved at mount time (explicit override → subdomain → query param → default). The data layer is swappable: it runs on local storage out of the box, and the same interface can be pointed at a real API/Supabase backend without changing the app. It ships two entry points — a standalone SPA and an embeddable widget.

Architecture


Church Connect — Multi-Tenant Resolution ══════════════════════════════════════════ Request Tenant Resolver (at mount) grace.connect.app ──► 1. explicit override (embed / data-tenant) 2. subdomain ← "grace" 3. ?tenant= query param 4. VITE_DEFAULT_TENANT │ Tenant registry ┌──────────────────────────┐ │ branding theme │ │ enabled features[] │ │ feature label overrides │ │ seed accounts │ └──────────────────────────┘ │ Feature registry (one place) Events · Announcements · Sermons Prayer · Leadership · Groups · Meals │ Swappable data layer localStorage ⇄ API / Supabase Entry points: standalone SPA + embeddable widget

Dev Notes

Problem Solved

Small churches rarely want to run their own app deployment. One hosted build that any church can adopt on its own subdomain — with its own branding and only the features it needs — removes that barrier.

Technical Highlights

Tenants, features, and feature labels are all data in registries, so onboarding a church is a config entry, not a code change. The data layer is an interface: localStorage for demos, a real API in production, with the same shape either way.

What's Next

A production API/Supabase backend behind the swappable data layer, per-tenant admin tooling, and deployment onto a shared subdomain wildcard so new churches self-serve.


View source on GitHub


Back to top