MWChope vs ShepherdOS
A feature-by-feature and architectural compare of Mo's Mountain West Church build (momwchurch/MWChope) against our ShepherdOS platform. Mo's is a deep, production-deployed church operating system; ours is a younger, SaaS-first platform with a cleaner modern stack and a few genuinely differentiated modules.
Mo's Build
Our Build
The headline
Mo is ~5× further along on raw feature surface — especially in staff/HR operations, worship planning, a full member-facing app, and integrations. We are ahead on a handful of strategic modules (habit engine, Bible reading plans, engagement scoring, AI-native architecture) and on stack modernity (tRPC end-to-end type safety, React 19). His is church-built-first but multi-tenant capable; ours is product/SaaS-first but earlier.
Architecture & stack
Same core choices (Next.js, Prisma/Postgres, Clerk, Anthropic) — different API philosophy and maturity layer.
| Dimension | MWChope (Mo) | ShepherdOS (Ours) |
|---|---|---|
| API style | REST (Express, 130+ routers) | tRPC 11 (end-to-end typed, 24 routers) |
| Frontend | Next.js 15.5 · React 18 | Next.js 15.5 · React 19 |
| Monorepo | npm workspaces · 4 apps / 6 pkgs | Turborepo · 3 apps / 7 pkgs |
| Auth | Clerk + DB-driven RBAC + API keys | Clerk + role enum |
| Background jobs | BullMQ + Redis (separate worker) | Inngest |
| AI | Claude — search, drafts, generosity, in progress | Anthropic SDK — habit coach, insights, narratives (native layer) |
| Email / SMS | Resend + Twilio + web/native push | Brevo (SMS/push schema-ready) |
| Multi-tenancy | Yes — Organization root, campus-scoped (built MW-first) | Yes — churchId scoping, plan-gated, white-label config |
| Observability | Sentry + Pino structured logs | None yet |
| Tests / CI | 100+ unit tests · 8 CI workflows | No tests · deploy workflow only |
| Hosting | Vercel (web) + Railway (API/DB/Redis) · live | Vercel · scaffold deployed |
Feature gap matrix
Grouped by domain. Each row shows build-out status in Mo's build vs ours. The verdict chip flags who leads each domain.
👤 People & Households
Mo leads✅ Check-In
Mo leads👥 Groups
Mo leads🎵 Services / Worship Planning
Mo leads big🙋 Serving / Volunteers
Mo leads💝 Giving & Generosity
Mo leads big📣 Communications
Mo leads🙏 Pastoral Care & Prayer
Roughly even🌱 Discipleship & Formation
We lead🏢 Staff Ops & EOS
Mo leads huge📱 Member-Facing App
Mo leads huge⚙️ Forms & Workflow Automation
Mo leads📖 Sermons & Content
Mo leads✨ AI Layer
Split — different bets📊 Reporting & Dashboards
Mo leads🔌 Integrations & Migration
Mo leads🏗️ SaaS Platform & Infra
Split — we lead SaaS, Mo leads infra🟢 Where ShepherdOS is genuinely ahead
- Habit engine (James Clear)Full identity-based habits, daily logs, streaks + AI coaching. Mo only has devotional entries. This is our #1 differentiator.
- Bible reading plansDedicated
@shepherdos/biblepackage with enrollment + completion tracking. Mo's is partial. - Engagement scoringWeekly at-risk tiering with trajectory baked into the model. Mo's is partial/unclear.
- AI-native architectureClaude wired as a first-class service layer (coaching, narratives, summaries) — not bolted on.
- SaaS plumbingStripe plan-gating + white-label config built for selling to any church.
- Stack modernityEnd-to-end type safety via tRPC + React 19 — fewer runtime surprises than 130 REST handlers.
🟡 Our biggest gaps vs Mo
- Entire member-facing appMo has 20+ member pages (self check-in, giving, sermons, messaging). We have an app shell.
- Staff Ops / HR / EOS suiteOnboarding, PTO, reviews, 1:1s, projects, surveys, SOPs, VTO — none of it built on our side.
- Worship planning depthSong library, arrangements, media, live control, evaluations. Ours is a basic plan model.
- Giving depthTax statements, generosity pipeline/AI, campaigns, pledges, budgets, reconciliation.
- Integrations & public APIPCO + Strety migration, webhooks, calendar sync, API keys.
- Production hardeningTests, CI, Sentry, structured logging — Mo is live; we're a deployed scaffold.
What I'd do with this
Mo has effectively built the broad "operating system." Rather than race him on surface area, the move is to borrow his proven schema/feature patterns where he's ahead and double down where we already differentiate (formation + AI). Concretely:
Mine his schema, not his code
His 339-model Prisma schema is a goldmine of field-level decisions (check-in pickup auth, song arrangements, generosity stages). Adopt the data shapes; we keep our tRPC layer.
Pick 2–3 domains to close fast
Member app + worship planning + giving depth give the biggest "feels complete" jump. Decide which matters most for the first paying churches.
Defend the moat
Keep pushing habits, engagement scoring, and the AI formation narrative — that's the thing Mo (and PCO) don't have. Make it undeniable before broadening.
Harden before we sell
Add tests, Sentry, and CI. Mo's production maturity is a real gap if we onboard real churches with real giving + member data.