The WhatsApp trap – why development programs outgrow informal tools

Every development program starts the same way.

A coordinator creates a WhatsApp group. A field worker shares a photo of a filled form. Someone makes a master Excel sheet and pins it to the group. A program manager creates a folder on Google Drive and shares the link. It works. The program runs. People are helped.

Then the program grows.

More field workers. More states. More beneficiaries. More data. More reports due. More people in the WhatsApp group. More versions of the Excel file. More confusion about which version is current. More time spent managing the tools instead of running the program.

Nobody decided to build a broken system. It grew into one.

WhatsApp is not the problem

Let’s be clear about something. WhatsApp is excellent. It’s fast, it’s familiar, it’s free, and almost every field worker in India already uses it. For a program in its early stages, ten field workers, one state, a few hundred beneficiaries, it does exactly what it needs to do.

The problem isn’t WhatsApp. The problem is using WhatsApp at a scale it was never designed for.

A messaging app is not a data system. A shared Google Drive folder is not a program management platform. An Excel sheet is not a beneficiary database. They can play those roles for a while, under the right conditions. But those conditions have limits  and development programs have a habit of growing past them.

The question worth asking isn’t “should we still be using WhatsApp?” It’s “have we already crossed the line where informal tools are costing us more than they’re saving us?“

What the crossing looks like

There’s no single moment when informal tools stop working. It’s a slow accumulation of friction that becomes so normal nobody notices it anymore.

Here’s what it looks like in practice.

Data lives in too many places

There are three versions of the beneficiary list. One in a Google Sheet, one in the coordinator’s Excel file, one partially entered into the system they started using last quarter. Nobody is certain which is most current. When a funder asks for the beneficiary count, it takes a day to reconcile.

Reporting becomes a project in itself. 

At the end of every quarter, a program manager spends a week compiling data from WhatsApp messages, photos of paper forms, and partially filled spreadsheets. The report gets done  but it took five people and seven days, and the data quality is uncertain.

Field workers become data entry clerks. 

They take notes on paper in the field, then type the same information into WhatsApp, then fill a form, then update a spreadsheet. The same data four times. They spend more time managing information than doing the work the information is supposed to track.

Nobody knows what’s actually happening. 

A program director wants to know how many beneficiaries were reached this week across all states. The honest answer is: we’ll know by Thursday, once we’ve collected all the messages and compiled the numbers. Real-time visibility doesn’t exist.

New team members take months to orient. 

The program’s institutional knowledge lives in group chat history, pinned messages, and the memory of whoever has been around longest. When a coordinator leaves, a meaningful chunk of operational context leaves with them.

If three or more of these sound familiar, the tools have been outgrown. Not recently, probably a while ago.

Why organisations stay stuck

Knowing the tools aren’t working and doing something about it are two very different things.

The most common reason organisations stay stuck is that the informal system, for all its friction, is familiar. The field workers know it. The coordinators know it. Everyone has workarounds. Changing the system means retraining people, disrupting routines, and spending money on something whose benefits are harder to see than its costs.

There’s also a trust problem. NGOs have often seen technology projects fail, platforms that got built, didn’t work the way they were supposed to, and got abandoned. The instinct to stay with something that works, even imperfectly, over something that might fail is rational.

And there’s a prioritisation problem. The program work is always more urgent than the infrastructure work. There is always a reason to wait until the next grant cycle, the next quarter, the next phase. The informal system creates constant low-grade pain rather than a single acute crisis, which makes it easy to keep deferring.

The cost of deferring is invisible right up until it isn’t.

What the transition actually requires

Moving from informal tools to a proper platform is not primarily a technology decision. It’s an organisational one.The technology part, building a beneficiary management system, a field worker app, and a reporting dashboard is the straightforward part, if you work with people who’ve done it before. What’s harder is the organisational work that makes the technology stick.

You need to understand your own program before you can digitise it. 

This sounds obvious. It isn’t. Most organisations, when they start mapping their own workflows for a platform build, discover that the process they thought they had is not the process they actually have. Field workers have developed variants. Coordinators have invented workarounds. The Excel sheet has columns that nobody can explain anymore. Understanding what you actually do,not what the org chart says you do. This is the first piece of work.

The transition needs to reduce friction before it adds it. 

The reason people revert to WhatsApp after a platform launches is almost always that the platform made the job harder, not easier. Good migration means identifying the most painful part of the current system and solving that first, visibly, for the people who feel it most. Win the field workers early. Everything else follows.

You don’t have to replace everything at once. 

The instinct is to build a comprehensive platform that does everything the informal system does, plus more. That instinct leads to eighteen-month builds and failed launches. The better instinct is to pick the one thing that is causing the most pain, usually data collection, or beneficiary tracking, or reporting  and solve that first, well, and small. Once that works and people trust it, the next piece is easier.

Someone has to own it. 

Not the vendor, not IT, not the project manager who’s already moved on. Someone inside the organisation whose ongoing responsibility includes the platform  who will collect feedback from the field, decide what to prioritise, and make sure the system keeps working. This person exists before launch, not after.

A useful way to think about timing

The right time to make the transition is not when the informal system has completely broken down. By that point, the program has already paid a significant cost  in data quality, staff time, and missed insights  and the transition becomes an emergency rather than a planned move.

The right time is when you can see the ceiling. When the program is growing and you can see that the current tools will not scale to where you’re going. When the workarounds are multiplying faster than the team. When the friction is manageable today but you know it won’t be in a year.

That’s the moment to start the conversation not to build immediately, but to understand what a platform would need to do, what the transition would require, and what it would cost compared to the cost of staying where you are.

Programs that make this move proactively build systems that fit their growth. Programs that wait until they’re in crisis build systems under pressure that often don’t.

The end of the “WhatsApp as system” era

There’s nothing wrong with starting on WhatsApp. Most of the best programs we’ve worked with did. It’s a sensible way to start something before you know what it will become.

But there’s a moment  different for every program, but unmistakable when you look for it  when the informal tools that got you here become the thing holding you back. When the cost of the workarounds exceeds the cost of the solution. When the program is ready for infrastructure.

That moment is worth taking seriously. Because the programs that scale the ones that reach 50,000 beneficiaries instead of 5,000, that operate across five states instead of one, that generate data their funders actually trust  are the ones that built the infrastructure before they needed it, not after.

There are other important reasons why most NGO technology projects fail. Give it a read here to avoid making one for your organisation.

Think201 builds digital infrastructure for NGOs, foundations, and development programs. If your program is hitting the ceiling of its current tools  or you’re thinking about what a platform transition would look like  we’d be happy to talk. Let’s Connect