I built Pews, a full-featured church management platform, in 48 hours. No team, no funding, just me, Claude, and 80+ AI agent runs orchestrated through an agent factory pattern.

Here's how AI agents are changing what a solo founder can build in a weekend.


๐Ÿง  The Problem

Church management software is a $500M market dominated by Planning Center. They charge $199/month for the full suite, member directories, online giving, volunteer scheduling, check-ins, service planning. Small churches under 200 members can't justify that spend. They're stuck juggling Google Sheets, paper sign-up sheets, and Venmo links for tithes.

I saw the gap. Build something opinionated, affordable, and modern. Target price: $100/month flat. Time budget: one weekend.

โš™๏ธ The AI Agent Factory

I didn't just use Claude in a chat window. I built an agent factory, spawning isolated sub-agent sessions each with a focused task, context window, and clear deliverable. 80+ agents across two overnight build sprints.

Friday night (6pmโ€“2am): Architecture & data model

  • Agents 1โ€“12: PostgreSQL schema design, multi-tenant from day one (every table has tenant_id)
  • Agents 13โ€“20: Go backend scaffolding, REST API with chi router, service layer pattern
  • Agents 21โ€“28: Authentication & RBAC (session-based auth, role claims, middleware)

Saturday (8amโ€“11pm): Frontend & features

  • Agents 29โ€“45: SvelteKit pages and components, member directory, groups, events, check-ins
  • Agents 46โ€“58: Online giving with Stripe Connect Express (churches get their own Stripe accounts)
  • Agents 59โ€“68: Service planning, volunteer teams, communication (email + SMS)

Sunday (9amโ€“3pm): Polish & deploy

  • Agents 69โ€“74: Dark mode, responsive design, onboarding flow
  • Agents 75โ€“80: Docker deployment, Traefik config, demo seeding
  • Manual: Testing, bug fixes, landing page at pews.app

Total agent runs: 80+. Roughly 12,000 lines of Go and Svelte generated. My manual contributions: maybe 500 lines of integration glue and bug fixes.

๐Ÿš€ The Tech Stack

This is where the subagent got it wrong in the first draft of this post, it assumed Python and React because that's what most AI-generated SaaS uses. Pews is actually:

  • Backend: Go 1.22 with chi router, clean service-layer architecture
  • Frontend: SvelteKit with server-side rendering
  • Database: PostgreSQL 16 (32 migrations and counting)
  • Payments: Stripe Connect Express, each church gets their own Stripe account, we take 1% platform fee
  • Auth: Session-based with bcrypt, role-based access control (Admin/Leader/Member)
  • Hosting: Docker on ctmprod (my AWS Lightsail instance), behind Traefik v2.11
  • Ports: Backend :8190, Frontend :5273, Postgres :5432

Why Go + SvelteKit? Go compiles to a single binary, uses minimal memory (critical when you're running 63 other containers on a 16GB instance), and the type system catches bugs before runtime. SvelteKit gives me SSR, file-based routing, and a reactive UI without the React/Next.js complexity tax.

๐Ÿ—๏ธ Multi-Tenant From Day One

Every query in Pews filters by tenant_id extracted from the authenticated user's JWT claims. This isn't an afterthought, it's baked into the service layer:

func (s *GroupService) List(ctx context.Context) ([]Group, error) {
    tenantID := auth.TenantIDFromContext(ctx)
    return s.repo.ListByTenant(ctx, tenantID)
}

One codebase, one database, infinite churches. A security bug in the Groups module early on let users see other tenants' data, caught and fixed by a dedicated security-sweep agent. Multi-tenancy is easy to get wrong and expensive to fix later.

๐Ÿ’ก The Agent Orchestration Pattern

Each agent run followed a strict template:

You are building a church management SaaS called Pews.

Stack: Go 1.22 backend (chi router, service layer) + SvelteKit frontend + PostgreSQL 16
Architecture: Multi-tenant (tenant_id on all tables, extracted from auth claims)
Repo: ~/Projects/pews

Your task: Build the [SPECIFIC MODULE].
Requirements:
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]

Existing schema context:
[Paste relevant migration files]

Deliver: migration file, Go service + handler, SvelteKit pages, tests.

The key: specific requirements, existing schema context, and clear deliverables. Vague prompts produce vague code.

Each cycle took 15โ€“30 minutes. Run the agent, review the output, test it, fix obvious issues, commit, move on. The overnight factory ran agents in parallel waves while I slept.

๐Ÿ“Š What AI Got Right

  • Boilerplate elimination. CRUD endpoints, form validation, error handling, generated cleanly across 12+ modules.
  • UI consistency. Once I established the SvelteKit component patterns, agents replicated them perfectly across 30+ pages.
  • Database design. 32 migrations with proper indexes, foreign keys, and constraints. Better than my first draft.
  • Full module delivery. Each agent delivered a complete vertical slice: migration โ†’ Go service โ†’ handler โ†’ Svelte pages. No half-finished features.

๐Ÿ”ฅ What AI Got Wrong

  • Cross-tenant data leaks. The Groups module initially didn't filter by tenant_id in one query path. Found it with a security sweep agent.
  • Migration numbering conflicts. 45 feature branches all using migration numbers 012โ€“015. Had to renumber before merging.
  • N+1 queries. Generated individual queries in loops instead of JOINs. Had to manually optimize hot paths.
  • Integration gaps. Features built in isolation meant I had to wire up relationships manually (e.g., connecting service planning to volunteer teams).

The ratio: AI wrote 90% of the code. I spent 90% of my time on the 10% it got wrong. That math still works out massively in my favor.

๐Ÿ’ฐ The Business Model

  • Pricing: $100/month flat (vs Planning Center's $199 tiered pricing)
  • Revenue model: Subscription + 1% Stripe platform fee on online giving
  • Target: Churches under 500 members who need real software, not spreadsheets
  • Demo: demo.pews.app (seeded with sample data, full feature walkthrough)
  • Domain: pews.app

There are ~300,000 churches in the US. Planning Center has maybe 70,000 of them. The long tail of smaller churches that can't afford $199/month is massive. If I capture 50 churches at $100/month, that's $60K ARR from a weekend project.

๐Ÿง  Lessons Learned

  • Agent factories compress time, not complexity. You still need to understand multi-tenancy, auth, payment flows. AI accelerates execution, not thinking.
  • Context is king. The more schema, existing code, and patterns you feed each agent, the better the output. Copy-paste your migrations.
  • Go + SvelteKit is an AI-friendly stack. Strong typing catches hallucinations at compile time. Svelte's simplicity means fewer framework-specific foot-guns.
  • Small focused tasks > big sweeps. An agent building one module perfectly beats an agent attempting three modules sloppily.
  • The moat isn't code. Anyone can replicate features with AI agents now. Distribution, trust, and customer relationships are the real differentiators.
  • Ship the demo. Having demo.pews.app with seeded data and a full walkthrough is worth more than a perfect landing page.

Pews is live. Demo's running. The feedback from pastor friends has been overwhelmingly positive. One said, "This feels like Planning Center but without the sticker shock."

AI didn't build my SaaS. I did. But AI made it possible to go from idea to 12 production-ready modules in 48 hours instead of 6 months. That's the game-changer.

Next up: PCO data importer so churches can migrate painlessly. Stay tuned.