DJ Lee & Voices of Judah

A booking-first site for a working gospel ministry — one Cloudflare Worker, a static front, and a booking form that validates submissions and forwards them by email without writing fields to an application database or browser storage.

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” in one continuous mobile-first flow, with the request forwarded through the configured email path. There was no CMS requirement hiding in the brief: this ministry doesn’t publish articles — it performs, posts to social, and takes bookings. One page to a sent request, an inspectable email handoff, and source-level content updates instead of a CMS workflow.

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, built as a Cloudflare Worker. The Worker validates each submission and forwards it through Cloudflare Email Routing to two mailboxes controlled by the ministry (one received on Apple’s iCloud Mail; the provider behind the second has not been independently confirmed); it does not write booking fields to an application database or browser storage. No separate form SaaS is used. Structured data ships as MusicGroup plus service-area Places for local discovery, and the public source keeps the booking path inspectable without a form-vendor handoff.

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. Deep WordPress experience 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.
• Narrow data path, on the way in: the single dynamic surface is /api/booking, a Cloudflare Worker that validates each submission and forwards it through Cloudflare Email Routing to two mailboxes controlled by the ministry (one received on Apple’s iCloud Mail; the provider behind the second has not been independently confirmed). The application does not write booking fields to an application database or browser storage. What happens to a message after it lands in a ministry inbox depends on those mailbox providers and the ministry’s retention practices, not on this architecture.
• An inspectable pipeline, as a consequence: the live form posts to one server-side /api/booking endpoint, and the public source shows the booking path rather than outsourcing the promise to a form vendor.
• A focused front door, as a consequence: with nothing serving but the funnel, the public artifact is the live Worker-served page and source repo, not a private performance claim. The page stays focused on one job: get a booking request sent from a phone.

Same rule as everything else on this site — trust is structural. Here it’s applied to a booking pipeline: the Worker validates and forwards each submission through Cloudflare Email Routing to two ministry-controlled mailboxes (one received on Apple’s iCloud Mail; the provider behind the second has not been independently confirmed), without a database or browser storage in front of it — checkable by reading the code, not just by reading the copy. What a receiving mailbox does with a message after delivery is outside what this architecture can promise.