Mission & CSR

Why Dada Salama is Open Source: Technology as Activism

Fewer than 3% of gender-based violence cases reported in Kenya reach prosecution.

That number hit the room differently depending on who was in it. A couple of us had encountered it before in civil society research. One person, our head of product, went quiet in a way that was not processing-the-statistic quiet. It was something else.

We found out later that her sister had reported assault four years earlier. She knew the number was right because she had lived it. The case died somewhere between the police station and the ODPP. Not because anyone decided to drop it. Because the system has no connective tissue, and cases fall through the gaps between institutions that do not talk to each other.

That is how Dada Salama started. Not with a grant. Not with a product roadmap. With a question about why a number that high was considered acceptable.

We Almost Did Not Build This

There was genuine internal debate. Months of it. The concern was not that the problem did not matter. The concern was that we are a software company, not a GBV organization, and that building a tool with false confidence baked into it could cause more harm than no tool at all. If a survivor used Dada Salama and believed her case was being tracked when it wasn't: because a caseworker didn't update the system, or a clinic's records were siloed, that false confidence could have real consequences.

The debate ended when our head of product said, plainly, that the alternative to a flawed tool was not a perfect tool. It was the spreadsheet she had watched her sister and a FIDA paralegal use to track a case that was eventually abandoned. The debate about whether to build it stopped. The debate about how to build it without causing harm got much more serious.

The Problem Is Not Reporting. It Is Navigation.

The framing that made Dada Salama possible, and that kept us from building the wrong thing, came from two months of fieldwork before we wrote a single line of code. We talked to caseworkers at FIDA Kenya, the Kenya Women and Children's Resource Centre, and gender desks at two county hospitals. We sat with survivors who had agreed to speak with us. We went to magistrate courts and watched the queue.

What we heard, over and over, was not "survivors don't report." Reporting rates in Kenya are low, but that is a different problem: one about stigma, safety, and trust in institutions, none of which software solves. What we heard was: survivors report, and then they get lost.

The GBV justice pathway in Kenya involves, in sequence: a police station (OB number), a medical facility with a P3 form and clinical examination, potentially a gender desk referral, the ODPP, and if the case reaches court, the magistracy. Each of these institutions has its own records, its own staff, its own backlog. None of them share a system. A police OB number does not automatically notify the ODPP. A P3 form processed at Kenyatta National Hospital does not travel anywhere unless someone physically carries it. Legal aid providers do not know a case exists unless someone physically calls them.

There is a 72-hour window for the P3 medical examination to be clinically valid for prosecution. Almost nobody tells survivors this. They show up on day four. The evidence that would have been captured on day one is gone.

Cases die in the gaps, not from bad intentions, but from a fragmented system that was never designed to move a case from one institution to the next without someone manually carrying it across every handoff.

So we built a navigator, not a reporting tool. Dada Salama does not replace reporting. It sits on top of the existing system and creates connective tissue where there was none.

Design Decisions That Came From Fieldwork, Not Product Brainstorms

USSD First

We had an early prototype: a clean web app, thoughtfully designed, accessible. We took it to two community testing sessions, one in Kibera and one in Mathare. Both sessions were humbling.

Most of the phones in the room were feature phones. Some had WhatsApp. A few had browsers that could technically render the app if they had data credit, which several did not.

The USSD decision: USSD became the primary interface, not a fallback, not an afterthought. It works on any phone, on any network, with no data connection, no app, no account. You dial a short code. The interaction is synchronous and session-based. For a system that needs to be reachable by a person in the worst moment of their life, on whatever device they have, USSD is the correct answer. It also leaves no app icon visible on the home screen: for a survivor whose phone is checked by an abusive partner, invisibility is a safety feature. The web dashboard exists for caseworkers and NGO administrators. The survivor interface is USSD.

Our WhatsApp-first advocate on the team, the one who had been arguing for a chatbot interface, conceded before we had to say anything. You do not get to impose a smartphone assumption on a problem that does not have a smartphone population. Mapping a multi-stage legal navigation flow onto USSD's 182-character menu constraints is not trivial engineering. We are proud of it.

Three States for Check-In

Standard welfare check systems have two states: fine, not fine. A caseworker calls or a system sends a prompt, and the survivor indicates whether she is okay.

A FIDA caseworker walked us through what this looks like when the abuser is in the room. The survivor answers the phone. She says she's fine. She is not fine. She is being watched.

Dada Salama has three check-in states. A normal code word. A distress code word. And a third code word, distinct from both, that means "I am being coerced into saying I am fine." Each triggers a different response protocol. The third code word does not involve police contact, because police contact is not always the safe response when the perpetrator is law enforcement, or when police arrival escalates danger in a specific household. It routes to a designated advocate in the survivor's network who can assess the situation and decide what to do.

That came entirely from one conversation with one caseworker. It is not something you design in a product sprint. You design it by listening to people who have been sitting with the consequences of the previous design for years.

The 14-Day Stall Alert

"Cases just stop moving and nobody knows why."

That was how a gender desk coordinator described the most common failure mode in case progression. Not a formal decision to close. Not a transfer gone wrong. Just nothing happening for weeks, and then months, until the case is effectively dead without anyone having officially abandoned it.

We built automated tracking on case milestones. Court date scheduled, medical referral processed, investigation status updated: each triggers a timestamp in the system. When fourteen days pass with no meaningful milestone update, the designated advocate gets flagged. Not an alarm, not an accusation: a signal that this case has gone quiet and someone should find out why.

Fourteen days is not a magic number. It came from asking caseworkers what felt like too long. Twelve days felt like it might generate too much noise on busy caseloads. Three weeks felt like cases could genuinely stall badly in that window. Two weeks was where the consensus landed.

It sounds obvious in retrospect. Nobody had built it because nobody had designed around the caseworker's actual experience of case loss rather than around reporting inputs.

Why Open Source

We could have built Dada Salama as a managed SaaS product and licensed it to NGOs. The economics would have been cleaner. We would have maintained control of the data model, the deployment, the roadmap.

We chose not to, for reasons that felt important enough to make the decision irreversible. Dada Salama is licensed under the AGPL. The source is public. Any organization can run their own instance. Forking is explicitly encouraged.

The logic is simple: we do not want to be a gatekeeper for infrastructure that should belong to the organizations doing this work. If FIDA Kenya wants to customise the intake form for their specific service model, they should be able to do that without asking us. If a county health department wants to integrate Dada Salama with their existing patient management system, they should not depend on our roadmap. If a women's rights organization in Uganda or Tanzania wants to adapt it for their legal context, they should not need our permission.

The deeper reason: we do not know what this problem looks like in five years. GBV support organizations understand their context better than we do. Open source means the tool can evolve with the organizations using it, not with the priorities of a software company that built it once and moved on. Any organization deploying Dada Salama should treat us as contributors, not owners.

The AGPL clause matters: if you improve it, those improvements come back to the commons. Not as a licensing weapon: as a mechanism for making sure the work compounds across organizations rather than being siloed in private forks. If an NGO improves the Somali-language USSD prompts, or adds a flow specific to Kajiado County's court circuit, those improvements return upstream.

The Honest Limitations

Technology is not the bottleneck. The justice system is the bottleneck. Dada Salama makes navigation better. It does not make justice faster. If the ODPP is understaffed and cases take three years to prosecute, our software does not change that. If a P3 examiner is not available because the county hospital has one doctor covering four wards, our software does not fix that either. We are not pretending otherwise, and any organization considering deployment should not pretend otherwise either. The tool will surface the backlog that was already there. Suddenly you can see exactly how many cases have been sitting for 90 days with no movement. The cases were always there. Now you can count them.

We have learned, concretely, that Dada Salama's impact is highest when it is embedded in a human support structure: when a caseworker at FIDA or GVRC is using it alongside a survivor, not when a survivor is using it alone. A woman who receives a USSD prompt telling her that her case should have been referred to the ODPP six weeks ago, with no caseworker to help her act on that information, may feel worse, not better. The navigation value is real. The isolation of using it without support is also real.

This has a direct implication for any organization considering deployment: invest in the human side first. The software is a multiplier on the caseworker's effectiveness. It is not a substitute for the caseworker. If you are thinking about Dada Salama as a way to cover more cases with fewer staff, think again. The right framing is that it reduces the coordination overhead of managing cases across fragmented institutions, but it does not reduce the need for humans who have standing with those institutions.

What Two Years of Deployment Taught Us

The cases that move fastest are the ones where a designated human advocate is actively involved from intake: someone who treats the case as their case, who knows the survivor, and who uses Dada Salama as a tool for their own case management rather than as a system that manages things for them.

The organizations best positioned to deploy Dada Salama are the ones with existing relationships with the police gender desk and the local ODPP office. The software creates the connective tissue, but those relationships determine whether the notifications get acted on. A 14-day stall alert is only useful if the person receiving it has the standing to call someone at the ODPP and ask what happened. Technology cannot manufacture institutional relationships. It can make those relationships more effective once they exist.

We have also learned that the legal flow assumptions baked into the system need constant maintenance. The Sexual Offences Act has been amended. Sentencing guidelines have changed. The ODPP has issued new prosecution policy directives. Every one of these changes requires an update to the decision trees that drive the navigation prompts. We cannot do this alone: we need lawyers engaged with the codebase on an ongoing basis, not just at the point of initial design. Open source is how we make that possible.

The core team now includes caseworkers who were using the system in the field and came back with requirements we would not have arrived at from the outside. The roadmap is driven by the deployment organizations, not by us. That is how it should be.

Dada Salama: Safe Sister

The name means "safe sister" in Swahili. We chose it deliberately. The system we built is not a product. It is not a brand. It is an expression of a belief that the people in our community who are most vulnerable to violence deserve the same quality of engineering attention we bring to our commercial work, and that the right structure for a tool like this is one that we can hand to others, step back from, and watch grow beyond us.

We will keep maintaining it. We will keep improving it. We will keep listening to the caseworkers and the survivors and the lawyers who tell us where it fails. But we do not need to own it. Any organization that can run a server and is committed to survivor safety can run this tool.

That has always been the point.

If your organization works in GBV response and you want to talk about deployment, not a sales conversation, a technical one, reach out at dada-salama@datacraft.co.ke. We provide setup support at no cost for registered organizations working on GBV in Kenya and the wider East Africa region. The repository is at github.com/datacraft-co-ke/dada-salama. Issues, pull requests, and forks are welcome. The code is yours.