Case study · 2026
Believers' Flame
One platform readers open each morning and editors use to plan, review, and publish without drift.
View live site
01 / Context
The brief was operational, not cosmetic.
The problem
Daily faith content needed a dependable publishing system, not a generic CMS, before editorial could plan and ship with confidence.
The intervention
Mobile-first public site, editorial admin, 52-week calendar, brief queue, share cards, WhatsApp channel, midnight auto-publish.
02 / System
Structure the work behind the surface.
Astro on Cloudflare Workers with D1 content store, draft-to-published workflow, and Johannesburg-timed daily delivery.
One platform readers open each morning and editors use to plan, review, and publish without drift.
03 / Decisions
Constraints shaped the system.
Constraints
- Editorial cadence is daily and seasonal — a 52-week calendar had to feel native, not bolted on.
- Readers arrive on mobile first; share cards and WhatsApp matter as much as the homepage.
- Auto-publish must land on Johannesburg time without requiring someone to stay awake at midnight.
- Faith content needs calm clarity — the surface cannot feel like a startup marketing kit.
Trade-offs
- Chose a purpose-built editorial admin over a generic CMS so the calendar, brief queue and publish rhythm stay in one mental model.
- Favoured Cloudflare Workers + D1 for edge delivery and a single content store instead of a heavier multi-service stack.
- Kept the public site lean (Astro) so editorial complexity lives in the admin, not in the reader experience.
04 / Evidence
Selected screen
05 / Readout
How the work moves.
The operational problem
Daily scripture, prayer and declaration only work if they arrive on time, every day, through channels people already open. Before Believers’ Flame, the gap was not “more content” — it was a publishing system editorial could trust: plan a year, brief a week, review a draft, and know midnight delivery would fire without manual babysitting.
Design and systems reasoning
The public site and the editorial layer were designed as one operating model. Readers get a calm, mobile-first surface for the day’s flame. Editors get a calendar, brief queue, share-card generation and a draft-to-published workflow that mirrors how faith media actually ships — not how a blog CMS assumes writing works.
WhatsApp and share cards sit beside the site rather than afterthoughts. Distribution is part of the product, not a marketing checklist.
Workflow
- Plan — 52-week calendar frames the year.
- Brief — queue holds what needs writing or review.
- Draft → publish — content moves through an explicit state change.
- Deliver — midnight auto-publish lands on Johannesburg time.
- Distribute — share cards and WhatsApp carry the same day outward.
Before → after
Before: Daily faith content depended on memory, scattered tools and a CMS that did not match the editorial rhythm.
After: One platform where readers open a dependable morning surface and editors plan, review and publish without drift between intent and delivery.
Observable outcome
The system ships a daily public surface, an editorial admin keyed to calendar and queue, and scheduled midnight delivery. The outcome is operational reliability — content that lands when it should, through the channels the audience already uses — not a vanity redesign of a homepage alone.