Church communications platform
A volunteer-built platform for churches to manage podcasts, newsletters, email and SMS campaigns, audience lists, users, services, and scheduled delivery.
- Audience
- Churches, ministry teams, communications volunteers, and subscribers
- Role
- Volunteer architect, product developer, and operator
Church communications were spread across disconnected workflows.
Publishing a podcast, sending a newsletter, maintaining subscriber lists, and coordinating email or SMS required separate tools and repeated manual work. Volunteer teams needed one dependable system that could support recurring communications without creating another full-time operational burden.
One platform connected content, audiences, campaigns, and delivery.
I built a communications system that manages podcasts, newsletters, users, services, audience lists, and email and SMS campaigns. Cloudflare Workers and D1 coordinate scheduled RSS monitoring, consent-aware subscriber state, inbound SMS commands, Twilio delivery, exports, and administrative reporting behind a low-touch operating surface.
What this case can and cannot prove.
Public evidence is classified so a private implementation, deployed system, measured result, and advisory artifact are never presented as equivalents.
- Deployed system
- Volunteer infrastructure is deployed and operating with scheduled delivery, subscriber controls, and administrative workflows.
- Private operational artifact
- Private operational recap. Captured August 13, 2026. Verifies cross-channel reporting for email delivery, SMS delivery, audience changes, podcast activity, and system health. The raw artifact remains private because it contains organization and subscriber information.
The result was a change in operating capacity.
These outcomes describe what the implementation made possible. They are not generic product promises.
Brought recurring podcast, newsletter, email, and SMS communication into one managed platform.
Reduced the manual coordination required to manage audiences, campaigns, services, and scheduled delivery.
Created a deployed platform that volunteer teams can use to communicate consistently with their communities.
The architecture followed the operating need.
The system was organized around an operating sequence people could understand, govern, and improve.
Organize
Maintain users, services, subscribers, and communication lists in one system.
Publish
Manage podcast and newsletter content as part of the same communication workflow.
Schedule
Use Cloudflare Workers to coordinate recurring and event-driven campaign delivery.
Deliver
Reach the appropriate audiences through email and SMS without rebuilding the process for every campaign.
The decisions, reversals, and evidence behind the result.
Each movement records how the work changed as evidence replaced the starting assumptions.
Outcome
The intended outcome was to give volunteer teams one dependable, low-maintenance system for consistently reaching their communities across podcast, newsletter, email, and SMS channels. The goal was broader than automating podcast notifications. It was to make recurring communication operable by the people already responsible for the work. This mattered because existing products were too costly, and their onboarding and integration requirements were too complex for many volunteer teams to manage independently.
Diagnose
The presenting need was to send SMS and email messages to communication lists. Examining the workflow exposed the deeper operating problem. The team also needed campaign controls, delivery history, cost reporting, list management, SMS consent and opt-out workflows, and a repeatable email design system. The problem was not a single notification integration. It was the absence of a governed communications system that volunteers could operate without reconstructing audience, delivery, and reporting processes for every campaign.
Design
One option was to assemble separate commercial products for signup forms, email broadcasts, podcasts, campaigns, SMS delivery, and reporting. That approach was rejected because the combined cost and integration complexity would have remained difficult for a volunteer team to operate. Each product also introduced a separate management surface. Choosing that model would have preserved fragmented lists, duplicated onboarding and audience work, and left volunteers without a common dashboard for managing communications across channels.
Decide
The first version centered on sending email and SMS messages. Once it was in use, feedback and operating evidence showed that reliable delivery alone was not enough. Volunteers still lacked a unified feature set, reporting remained incomplete, delivery failures needed better diagnosis, and SMS consent and provider requirements created additional operating complexity. The original delivery-focused scope changed. The system expanded into a fuller communications platform with a common dashboard, campaign controls, templates, subscriber management, segmentation, delivery history, failure tracking, and cost reporting.
Execute
The platform deliberately left podcast hosting, the public website, payment systems, and full marketing automation outside its scope. It connects to the content and audience workflows those systems support without attempting to replace every existing responsibility. Keeping those boundaries avoided unnecessary migration and reduced the number of systems a volunteer-built platform would need to maintain. The work stayed focused on the shared communication layer: audiences, campaigns, consent, delivery, and operating visibility.
Transfer
Church staff and volunteers can maintain communication workflows independently through the platform. They can manage audiences, campaigns, content, schedules, templates, delivery history, and reporting without depending on the original builder for routine operation. I continue to handle technical maintenance as volunteer work. This separates day-to-day communication ownership from the application, integration, and infrastructure maintenance required to keep the service available.
Measure
The unexpected result was that aggregate send totals were not sufficient for operating the service responsibly. When delivery failures occurred, a total failure count did not identify which recipients failed, why they failed, or whether a later attempt resolved the problem. That reporting gap changed the system. The platform added per-recipient failure records, error details, resolution tracking, delivery summaries, and a cross-channel health recap covering email, SMS, audience activity, podcast performance, and system status.
I built and operate the platform as volunteer service.
My contribution spans product definition, architecture, implementation, integrations, deployment, and ongoing operation. The work applies the same production discipline as my commercial systems to organizations whose communications depend heavily on volunteers.
Working through a similar decision?
Bring the desired outcome, the systems already in place, and the constraint keeping the work from moving. The first conversation will test whether the problem is architecture, ownership, data, capability, or execution.