Masevo

Why churches need their own marketing tool

Hailo Global came in with a sharp insight: churches do social media badly because generic schedulers don't fit their workflow. A volunteer is posting on Sunday morning while running between rooms. The pastor's sermon notes are in Google Docs. Branding lives in a dropbox folder one person owns. Buffer and Hootsuite assume a marketing manager with time to draft posts — churches have a youth pastor with twenty minutes between services.

Masevo is the platform built around that reality. Multi-tenant from day one (each church gets an isolated workspace), AI-drafted social posts from sermon notes, a visual content calendar built for non-marketers, brand kits that enforce the church's look without anyone needing to think about it.

What I built

The brief was a high-fidelity demo + a Replit Agent build prompt that the client could hand to engineering for production. I delivered both as a single Next.js 14 app with the full visual system, working scheduling UI, mock multi-tenant routing, and an AI integration that genuinely drafts posts from arbitrary sermon notes.

• Workspace-per-church architecture — Supabase row-level security policies scoped to workspace_id so every query is automatically tenant-safe. New churches sign up and get an isolated workspace in under sixty seconds.
• AI sermon-to-social — paste sermon notes, get a week of platform-specific posts (Instagram square, Facebook longer-form, X threadable). Uses Claude Haiku for cost — drafting fifty churches' weekly posts costs about $4/day in API calls.
• Visual content calendar — drag-and-drop scheduling. Bulk-schedule a whole month from a sermon series.
• Brand kits — one-time setup, then every post inherits the church's logo, color palette, voice, and CTAs.
• Stripe billing wired with three tiers (Solo / Growing / Multi-campus) plus a generous nonprofit discount path.

Stack rationale

Next.js 14 + Supabase is my default for any multi-tenant SaaS — the App Router's server components let dashboards render with workspace data before hitting the client, and Supabase's RLS makes tenancy a database concern rather than an application concern. (Tenancy in app code is how data leaks happen.) Drizzle ORM gives me type-safe queries against the Supabase Postgres without giving up the RLS guarantees.

For AI, I went with Claude Haiku over Sonnet. The drafting task is structured (sermon notes → JSON of posts), the tone is constrained (every church has a brand kit that pre-shapes the prompt), and Haiku is fast enough to feel synchronous. Sonnet would have been overkill at 8x the cost.

What the client took away

The deliverable was three things in one repo: the working Next.js demo, the Replit Agent prompt to scale it to production, and a Loom walkthrough of how the architecture decisions map to the cost model they pitched investors. Hailo used the demo in their seed-round materials and it tested well with three pilot churches before they'd written a line of production code.

If you're building a B2B SaaS with workspaces

The hardest part isn't building features — it's building tenancy correctly. Almost every SaaS bug I've seen in client codebases is a tenancy leak (one workspace seeing another's data). Solving that at the database layer with RLS instead of in app code is the difference between sleeping well and getting paged at 2am about a privacy incident. Read more about how I architect multi-tenant SaaS.