The operating system for the local church — built so any church can run it, white-labeled.

We don't just tell churches who showed up. We tell them who's growing — and we wrap it in an AI layer no other church software has. This is the live build plan toward a fully working v1 a real church can trust with real people.

Live

Production

app.shepherdos.org · healthy

~35%

Real completion

wide & shallow → deepening

5 / 5

Security gate (crit+high)

fixed this session

Builders + Claude Code

Mario · Mo · Daron

The V1 Plan — four workstreams to a fully working build

WS-01

Security Gate

Close every hole before real congregant data goes in: secret hooks, staff-only data gating, audit logging, locked public forms, timing-safe webhooks.

7 / 10 itemsIn progress

WS-02

White-Label SaaS Layer

The differentiator. Per-church branding, custom domains, plan-tier gating, tenant provisioning — the platform layer single-church builds never need.

designedNext

WS-03

Make Everything Work

Module-by-module sweep of ~60 pages: every button real, every query live, no demo-data leaks. Worship/Services gets ported to full depth.

catalogedNext

WS-04

Trust & Isolation

First tests (currently zero), realistic seed data, real Prisma migrations, and an isolated instance for MW's real congregant data — separate from the product build.

plannedQueued

Who's building what · and why it stays one product

Team & ownership

Non-overlapping lanes. Every change ships via PR → preview → review → CI gate → merge.

Mario@shepherdostech-cloud

Architecture, security, white-label, AI engine. Reviews every PR. Drives the platform moat.

Mo@momwchurch

Worship / Services — the Planning Center killer. Porting his proven worship + serve-team schema (gatherings, teams, scheduling, songs) into our stack.
his lead modulealready built it at MW

Daron@darongeorge

UX polish + the must-fix bugs. Smart-search fix, pagination, dashboard/giving role-gating, rate limiting.

The moat — what no one else has

Two things keep this from being "another church CRM."

Formation over activity

We track the full discipleship arc — habits, groups, serving, giving, milestones — as formation data, not just attendance.

AI that makes it living

Claude reads patterns, flags at-risk members, coaches habits, and writes the weekly state-of-the-church narrative.

White-label, multi-tenant SaaS

Any church signs up, configures their own language and brand, and runs independently. The platform layer single-church tools never build.

Join the build · repo access & workflow

Get into the repo

Private repo on the MDH-Labs org (GitHub Team — seats available).

Get added

Send Mario your GitHub handle. He adds you to MDH-Labs/shepherdos with write access.

Clone & install

Authenticate with the GitHub CLI, clone, and install (the workspace needs the legacy-peer-deps flag for React 19).

gh repo clone MDH-Labs/shepherdos
cd shepherdos
npm install --legacy-peer-deps

Configure env

Copy .env.example into apps/admin/.env.local and fill the keys from the team vault. Full steps in TEAM-ONBOARDING.md.

Run it

npm run dev from apps/admin. Sign in, complete onboarding, you're in.

How we ship (one product, no fragmentation)

Same rails for every builder — and every Claude Code session.

Read the constitution first

Every session starts with CLAUDE.md + your section of memory/ASSIGNMENTS.md + docs/v1/RECON-2026-06-12.md. Non-negotiables: churchId-scoped, tRPC, generic naming, white-label-safe, TS strict, shared UI kit.

Branch → PR → preview

Work on a branch. Open a PR — GitHub Actions builds a live preview URL. No Vercel seat needed (Option B deploy).

Review + CI gate

Mario reviews; the Build and deploy check must pass. Schema changes (anything in packages/db) always get a heads-up — the schema is the contract.

Merge → production

Merge to main auto-deploys to app.shepherdos.org. Short branches, merged often.

ShepherdOS · a product of MDH Labs · internal — do not share outside the team