The default reflex
When a project needs an incident reporting platform with a map, the default reflex in the development sector is to reach for an existing open source platform like Ushahidi. The reasoning is sound at first glance. The platform exists, it has a community, it has been used in dozens of contexts, and starting from a working product feels safer than building from scratch.
The reasoning sometimes holds up. For standalone reporting projects with general purpose requirements and no need for tight integration with anything else, adapting an existing platform is genuinely the right call. The work is reduced to configuration, theming, and operational support, and the project gets to a useful state quickly.
Where the default reflex fails
The reflex fails in three situations. The first is when the reporting platform has to integrate cleanly into a wider ecosystem with its own data model, authentication, and user experience. Adapting an existing platform means reconciling two architectures rather than designing one. The cost shows up in the integration layer first, then in every subsequent feature that has to span the boundary.
The second is when the security and data handling requirements of the reporting workflow are specific to the audience. Existing platforms have their own assumptions about who reports, how reports are stored, who can access what, and how data flows out to advocacy and policy work. Adapting them to a different threat model is harder than designing a model that fits the audience from the start.
The third is when the long-term maintenance burden of the adapted platform is higher than the maintenance burden of a native build. Adapted platforms tend to drift from their upstream over time, accumulating local patches that are expensive to carry forward. A native build with a clear architecture, by contrast, can be evolved cleanly over the lifetime of the project.
The decision we made for DigiWatch
PANEOTECH delivered DigiWatch, the real-time incident reporting and mapping tool for the CiviConnect platform hosted by Jeunes Verts, under the digital resilience workstream supported by the Digital Defenders Partnership Sustainable Protection Fund. The original plan envisaged adapting Ushahidi. After assessing the integration, customisation, and security requirements against the platform's wider architecture, the decision was made to build natively.
The native build let the data model align with the rest of the CiviConnect platform. Authentication, user identity, and access control flow from the same source. The reporting form, the validation rules, and the storage layer were designed for the security profile of West African civil society reporting rather than retrofitted from a general-purpose default. The interactive map integrates with the platform's broader visual system rather than running as a separate visual identity.
The cost of the native build was real. So were the benefits. The platform now has an incident reporting layer that fits the rest of the system rather than sitting alongside it, with a maintenance trajectory that the technical team can carry forward without managing drift from an upstream the team did not control.
The architectural lesson
The build versus adapt decision has no universal answer. The discipline is to make the call deliberately, on the strength of the integration requirements, the security profile of the audience, and the long-term maintenance trajectory. Adapt when the integration burden is light and the requirements are general. Build native when the platform has to be part of a wider ecosystem with its own data model, security profile, and long horizon.
