276 – The Agency Fund’s Social Sector Tech Stack: The Front End

[00:00:07] Santiago: Hi, and welcome to the IDEMS podcast. I am Santiago Borio, an Impact Activation Fellow, and I’m here with David Stern, one of the founding directors of IDEMS.

Hi, David.

[00:00:17] David: Hi, Santiago. I guess we’re gonna carry on with our discussion on The Agency Fund’s recent article, a recent article on “A Default Tech Stack for the Social Sector”.

[00:00:30] Santiago: Yes, and we covered in our last episode a lot of the backend side that they proposed, and we were hoping to focus a bit more on the front end. 

[00:00:40] David: Yes, absolutely. So let’s dig into that. Broadly, let’s just remind people that in the back end there was this discussion about the AI stack and the observability and learning stack. And then at the front end, they had these three pieces, the frontline worker, the mobile chatbot, or the custom application. Should we just dig into that? Maybe starting with the frontline worker services.

[00:01:07] Santiago: Sounds good.

[00:01:09] David: I guess, let’s first be clear with the front end, this is really different ways, different people, interact with such systems. The mobile chatbot, which we’ll get to, this is the fact that people are building these chat engines that interact directly with people through WhatsApp and other, could be Weibo, it could be Viber, it depends where you are in the world, and Telegram is another one, which is used in Ethiopia. All these different mobile services for messaging, messaging services.

And then of course the custom apps, these are, as we build for PLH, these are, let’s say, Android apps, iOS apps, for Apple devices, web apps, which you sort of download and use through a browser. These are the custom apps that would be built.

So let’s dig in first to the frontline worker services. 

[00:02:03] Santiago: Before, let me ask you, so this front end stack is more about how the people we work with in social impact spaces will interact with the tools that we described in the last episode. Is that correct?

[00:02:20] David: Well, not necessarily the tools that we described in the last episode, that’s an interesting question, whether or not the AI agents interact directly with the frontend stack or not is a really interesting question. This comes back to the determinism that we said, but certainly it is this fact that however you are doing, if you are actually working with people, what are you doing, are you interacting with them, are you going through an intermediary, which is the frontline worker services, are you going through where they are already, which is often in a messaging service such as WhatsApp – a lot of people are on WhatsApp – or are you going through a new app which they’re downloading and putting on their device, or they’re accessing through a website? Those are the three choices. So the people you are interacting with, how are you interacting with them?

Let’s start with these frontline worker services and what they mean by this. Well, really it is this fact that quite often people are getting data through intermediaries, they have field staff who go out to collect data by working with people who maybe fill in questionnaires, who have a way of interacting, maybe interviewing people, and then uploading that data in different ways.

And there’s a whole set of different tools around this. The one that they choose as the default is interesting, it’s SurveyCTO, which is good, but it’s very interesting to me that it’s what they start with because in their alternatives they mention things like ODK, and KoBoToolbox.

[00:03:55] Santiago: Yeah, I assumed that ODK would be the one for us. But I’m not well informed enough to make a decision like that.

[00:04:03] David: Well, the point is, ODK and KoBoToolbox is great if you’re doing one-off surveys, but the reason that they are putting forward SurveyCTO, and of course the associated CommCare, is that actually a lot of work has longitudinal aspects to it. And this is a big Achilles heel of the ODK KoBoToolbox ecosystem at the moment, it remains its big Achilles heel.

I’m really interested that that has led to the fact that the default as is put forward here is simply SurveyCTO, and more than that, that’s seen as the easy option. Whereas in a lot of the worlds we work in, ODK often through KoBoToolbox and other providers has become what I would consider standard. And the reason for that is because of what’s called XLSForms. They have this way of authoring in Excel the questionnaires, the surveys.

And the number of researchers and other partners that we’ve worked with love the ODK system for questionnaires and surveys because they learn how to use these spreadsheet authoring tools and then it’s in their control and they own it in a way that I’ve not seen with anything else.

So it’s really interesting to me that this isn’t something which is here chosen as the default. It’s mentioned, of course, and I understand why it isn’t, but it’s really interesting that there is a difference in terms of the worlds that I suppose we’re working with versus maybe where they’re coming from, where the longitudinal studies are so important.

If you’re going for health data, ODK is a nightmare because it’s hard. It was hard and it remains hard to do good longitudinal studies compared to tools like SurveyCTO. But in other ways, ODK and particularly the spreadsheet authoring of ODK is so well received in so many contexts. And yeah, it’s a really interesting one, these are both put there, they’re both there, there’s not much I think to say more because what’s interesting is of the three front ends, this is the one which is very much based on the fact that you have extension agents of some form, intermediaries involved in a data collection process, be it one off or longitudinal. 

[00:06:44] Santiago: And this is particularly relevant for the social impact space or for the not-for-profit space that they talk about in the article in general. This is where I think it starts becoming more relevant to this space than the back end, or that’s the impression I’m getting at least.

[00:07:05] David: It’s not that it’s more relevant, it’s that this is the world that people are already working in. Many people in that space might have been using ODK or SurveyCTO for years. I guess what I want to finish with here is, a few years ago, we had colleagues in Mali who were wanting to build an app and my encouragement to them was, you are not yet ready to build an app because you don’t know what it is you are wanting to do in terms of the interactions with farmers. Start by building these forms, which sort of determine the data you are wanting to use, and then we can actually take it and sit and turn it into an app. 

They actually ended up building ODK forms. And we are actually in the process, we’ve just had these interns in Mali, who have taken what they did in ODK and built now what is the third one, which is the custom app based on it. But the point is that there’s other people who have started with surveys in ODK, and we’ve actually had to build chatbots for them, which collect that same data through chatbots.

And I found it very interesting, so if we move on to the chatbot services, these are tools which interact with WhatsApp, Telegram, they could interact with SMS, but that’s more expensive now unless it becomes less and less used or even a telephone sort of loop. But once you are actually wanting to have something which is interactive, this is a step beyond what we previously talked about, where you need that extension agent.

I’ll come back to something, I’ll come back to what we’re building a bit more at the end, where actually these things all come together. But they talk about Glific, they talk about Turn.io, they talk about Twilio, and Exotel. And what’s really interesting is that they don’t mention RapidPro.

[00:09:00] Santiago: I was gonna ask about that.

[00:09:02] David: Yes. And so the point is Glific is actually derived from RapidPro and they’re really good. It’s a really good engine group who have done this and they’ve done some really good work taking it beyond what RapidPro’s originally done. Turn.io, actually this has come out of the group who worked on IOGT before us, and so we followed what they’ve been doing. These are both groups that we know and we’ve interacted with, but they went specifically to WhatsApp. I don’t know that Turn.io works on all the different platforms, so it might depend on which country you are in, whether or not that’s the right choice for you.

It is beautiful some of the things they’ve done, they’ve got a really nice way of coding up their systems, their flows. But both of these , if you want, have emerged from the original open source tool, which was developed by and for UNICEF, called RapidPro. And RapidPro, it has its problems, but it focused on the fact that it was independent of the delivery mechanism, and so it works across a whole range of different delivery mechanisms.

And this is what we’ve continued to use a lot for the chatbots that we build. I’m not saying that you should use RapidPro, that people should use RapidPro above Glific or Turn.io, they both have advantages over RapidPro, but we believe that RapidPro as a foundation of technology has got a lot right. And so building from that with the technical expertise has other advantages as well. And it’s a really good team who’ve built it.

So all of these have really interesting teams behind them, they have different business models behind them, it’s really exciting that this is a space which is worth it, which people are engaging in. The problem is that recently all our work in this area got disrupted because we were going through UNICEF, and UNICEF and Meta, their agreement on WhatsApp elapsed and suddenly UNICEF turned off all its chatbots. So we had partners who were using this in Mexico and all over the place, where from one day to the next UNICEF suddenly said, nope, we can’t do this anymore because of the agreement with Meta, which has lapsed and therefore we can’t have these chatbots in WhatsApp.

And that’s irrelevant as to what you’re using, that’s the agreement about how much you’re spending and what you are paying for. And this is the real problem with the mobile chatbot services at the moment, that they are dependent on the ecosystem beyond your control and on agreements about delivery of this, which can have huge cost implications where this can change from one minute to the next and has been changing. Over the last three years we’ve had three disruptions to our work on this because of change in agreements like the change between UNICEF and Meta, which stopped everything for a number of months earlier this year.

And so really, the custom application piece, what’s really interesting there is this is something where they’re saying this needs to be built, you need a one or two person engineering team, you need to have tech developers to develop this. Whereas I’m not sure that this is necessarily gonna be true anymore.

I mean, our Open App Builder is exactly aiming to bridge this gap, but we are not the only ones, there’s other people building these no code solutions for this. And this is gonna move really fast with the interventions, the way code is now being written and generated with AI. So my guess is this is the only piece here where I feel this is maybe out of date as soon as it’s been written, because this is assuming that you need coders to build yourself a custom app.

And I don’t believe that’s true. I think they should be, you should be looking at these sorts of no code solutions to build apps. And as I say, we’ve been building the Open App Builder for these parenting apps, so there is one instance of that, but we are not alone, lots of other people are doing this in other spaces. It’s really, it’s an active area. 

[00:13:22] Santiago: And it’s something where all the backend that we discussed in the previous episode can come in and help develop these apps with no code solutions, isn’t it?

[00:13:34] David: Well, possibly. So that’s what we are building into the Open App Builder sort of systems. However, what they’re saying is that you use these AI coding agents like Claude Code to actually then build up using a tech stack here. And they have a tech stack, which is actually very similar to the tech stack we use, it’s the JavaScript tech stack. They suggest Next.js. We use something else. They suggest FastAPI, which is not bad. They suggest Postgres databases, which we use a lot. They suggest Tailwind, which we’ve used as well. They suggest Vercel or Railway as a deployment platform. We don’t actually use the deployment platforms, we deploy ourselves, and it is possible, anyway, yeah.

But these are all sensible things that they’ve got. And it’s just that I don’t think you need these. My hope is within a year or two, you won’t need a couple of engineers in the small NGO to build out your custom app. We need to make that easier, that needs to be as easy to take ownership of as your ODK forms for your extension agents.

And that’s the key. Actually at the heart of what we found is we are now building the apps and the facilitator apps, so that instead of the ODK forms, the facilitators have their own apps, which help them with their interactions. And so you don’t lose your extension agents or the people interacting because you are building your custom applications. You then integrate their experience into the experiences you’re building.

If we can make the development of these custom applications easier, then this is actually going to bring together a number of different things because then the chatbot doesn’t need to be separate, it can actually be integrated. You can have something which integrates meeting people where they are in WhatsApp, but also then actually integrated into the applications you are developing. Having a chatbot within an application, that’s an easy thing to achieve as well.

So there’s lots of things that can be done now. So this is a space where it’s really exciting to see where they’ve got this to, but it’s also really exciting to know that this is still early days, even six months a year down the line, this is likely to become a living document, there’s likely to be some interesting advances. And my guess is this will be a conversation which really starts about how do we actually build the open infrastructure which enables small organisations, social organisations to have, to own, to build the technologies that they need, which take advantage of the latest advances, but are not locked in, and they’re affordable, they’re achievable, and they’re powerful.

This is all possible and it’s exciting that The Agency Fund is sort of pointing the way on this.

[00:16:19] Santiago: Yes, and the whole objective is to give agency to more organisations.

[00:16:26] David: It is exactly what The Agency Fund is all about. This is what we’ve been working towards, they’ve articulated it very well, they’ve outlined, really, a lot of what it takes to put this together. I guess the question is, if you are in a local social enterprise somewhere, or an NGO, if you see this list, does this give you agency or does this make you feel, whoa, I’ve bitten off more than I can chew?

Can we cut this down? Can we actually say, okay, let’s make this not quite turnkey, but these are the things that you need to get started to do this yourself? I would love to actually try and say what would it take to make this into something where this whole technology stack is so much more accessible for that small social enterprise, that small NGO, that social organisation.

[00:17:17] Santiago: And can we build an overarching interoperable system that allows to plug in certain of these tools depending on the need.

[00:17:28] David: Absolutely. You know, we’ve gone through the parts of this report, which really relate to the tech stack that they’ve mentioned, but they’ve also got this whole other part of the report, which I really like, which are their lessons from the field, so to speak. So I really encourage people to go look up this report. I think we need to give them real credit for the work that’s gone into this. I hope it’s just the beginning of actually changing what is possible in this space. So it’s a really exciting report and nice to have discussed it, so thank you.

[00:18:02] Santiago: No thank you, David.