DJ Lee & Voices of Judah

A booking-first site for a working gospel ministry — one Cloudflare Worker, a static front, and a privacy promise the architecture keeps.

Problem

A working ministry’s front door isn’t a website — it’s a booking request. DJ Lee & Voices of Judah serve churches, families, and event planners across Chicago and Northwest Indiana, and the job was getting those people from “found you” to “request sent” on one screen, with the request landing reliably in the ministry’s inbox. There was no CMS requirement hiding in the brief: this ministry doesn’t publish articles — it performs, posts to social, and takes bookings. One screen to a sent request, dependable delivery, nothing to maintain between bookings.

Build

The second design is one Cloudflare Worker. It serves a static one-page front — about, events, music, gallery, booking — and exposes a single server-side endpoint, /api/booking, that takes the form post and emails it from booking@thevoicesofjudah.com to the ministry’s inboxes. No form vendor, no third-party processor in the path. Structured data ships as MusicGroup plus service-area Places for local discovery; robots.txt declares explicit content signals for AI crawlers; observability runs at full sampling, so the pipeline is traceable end to end.

It’s the second design because the first one taught me what to delete. Version one was built like a product: a React single-page app with session storage, a headless-commerce SDK, and Workers AI product suggestions — all of it still public in the dj-judas repo. What it taught: the funnel is a booking request, and everything that isn’t the funnel is weight. The rebuild was subtraction, and the diff is the receipt. Seventeen years of WordPress is exactly what qualifies me to say this client didn’t need WordPress — or a framework. Right-sizing the stack is fluency, not disloyalty.

Outcome

• One stack choice, shipped twice: the entire site is a single Worker serving a static front — live at thevoicesofjudah.com, with both designs public, dj-judas through dj-judas-v2. The iteration isn’t claimed; it’s diffable.
• Privacy by construction: because the only dynamic surface is /api/booking and submissions route from the Worker straight to the ministry’s inboxes — no form vendor — the form’s promise, “your info is only used to reply to your request,” is enforced by what the system is, not what the copy says.
• A measurable pipeline, as a consequence: observability runs at full sampling on the Worker, so every booking submission is logged and traceable end to end. The pipeline’s health is a dashboard read, not a guess.
• A light front door, as a consequence: with nothing serving but the funnel, the complete interactive page — markup, styles, script — measures about 22 KB before media, served from edge cache. It loads instantly on a church secretary’s phone, which is the point.

Same rule as everything else on this site — trust is structural. Here it’s applied to a booking pipeline, where “we only use your info to reply” is enforced by what the system does, not what the policy promises.