The church committee at a growing congregation on the outskirts of Mbarara had, by pure luck, an actual software engineer among its members — a young man named Denis, who worked remotely for a company in Kampala and attended the 10am service most Sundays when a client deadline didn't eat his weekend. When the committee complained, for the third meeting running, about how much manual work went into reminders, Denis offered to "just build something," and mentioned Africa's Talking, the SMS API platform he already used at work.
He wasn't wrong that it could do the job. Africa's Talking is a genuinely capable, pan-African SMS, USSD, and voice platform, built with a developer-first approach — REST API, SDKs, the works — and operating across multiple African countries including Uganda. For someone who already knows how to write code and wants full, custom control over exactly how and when messages fire, it's a real, serious option. Denis spent a free Saturday wiring up a script that could, in theory, text every member on a reminder schedule.
Then Denis got busy. A client project in Nairobi picked up, three Sundays passed without him touching the script, and the committee was back to a volunteer manually typing reminders into a phone, because the one person who understood the integration had a day job that didn't leave room for church IT on demand. Nobody else on the committee could open the code, let alone fix it when a field name changed or the script quietly stopped running one week.
The honest limitation isn't the platform. It's the requirement.
This isn't a knock on Africa's Talking — it does exactly what it says it does, and does it well, for the audience it's built for. The limitation is structural, not a flaw: an API is a set of building blocks for a developer to assemble, not a finished tool a non-technical church admin opens and uses. Recurring or triggered sending — "text every visitor automatically the day after they sign up," which is precisely the kind of thing a church actually wants — generally requires that developer-facing tier and someone who can write the integration code to make it happen. If that someone is a volunteer with a day job elsewhere, the system's reliability is only as good as their spare Saturdays.
Most churches don't have a Denis. And even the ones that do shouldn't have their Sunday reminders depend on one person's availability, because the moment that person moves to a different city, gets busier at work, or simply stops attending, the "system" quietly stops existing, and nobody left behind knows how to fix it.
What FaithDash hands over instead
FaithDash's automation covers the same underlying need — visitor follow-ups, event reminders, attendee follow-ups — but the "building" step is a form, not a codebase. Setting a rule like "send a reminder 24 hours before the event, to active members" happens through the Automation section: pick the trigger, set the timing, write the message with placeholders like {{name}}, {{event_name}}, and {{event_date}}, toggle it on. No script to maintain, no engineer required, and critically, no single person the whole system depends on — anyone with admin access can open the rule, read exactly what it does, and adjust it.
The messages still travel the same basic route — SMS gateway infrastructure connected to the Uganda telcos, priced at UGX 35 per SMS part, paid from the church's prepaid balance. FaithDash isn't a cheaper way to move a text than Africa's Talking; for a technical team building custom integrations at scale, the API tier can make good sense. The difference is who has to be in the room for the system to keep working on a random Tuesday when nobody who understands code is around.
Both have their place
If your church has an in-house developer with time to spare and wants something entirely custom-built, Africa's Talking is a legitimate, well-regarded platform to build it on. But for the overwhelming majority of churches — where communications runs on a volunteer roster, not an engineering team — a tool that hands over automation through a form, not a codebase, is the one that's still working three years from now, long after whichever volunteer set it up has moved on.
Denis still comes to the 10am service when he can. The reminders don't wait for him anymore.