Finding Better Ways to Build Digital Solutions for NGOs
Adapted from: Henrik Kniberg
This post explains Hikaya's iterative approach to building digital solutions for NGOs: starting with a functional "skateboard" rather than trying to build a perfect "car" from day one. By delivering working products at every stage and gathering real-world feedback, organizations end up with solutions better adapted to actual user needs and constraints, saving time and money while producing stronger end results.
Key Takeaways
- Build functional solutions at every stage (a skateboard before a car) so users can provide feedback throughout development
- Start with a minimum viable product (MVP) and iterate based on real-world usage, not assumptions
- Working iteratively reveals user needs that wouldn't surface from blank-slate requirements gathering
- Asking deeper questions early (like "could this scale to other projects?") saves significant rework later
- This approach breaks from traditional NGO project management logic but leads to better, more adapted digital products
Why iterative development matters
The comic above captures how we build digital solutions for NGOs: deliver something functional at every stage, collect feedback, and improve.
The first row, "Not like this", shows the trap of building a perfect wheel, then an axle, then a chassis. The user gets nothing until the car is complete. The second row shows the alternative: a skateboard, then a bicycle, then a motorbike. Each one moves people from A to B, and each round of feedback shapes what comes next.
In practice this means breaking from the typical NGO development pattern of pre-conceptualized, highly designed, rigid projects where learning happens at the end (if at all). Iterative development flips that: start with a skateboard, use it, learn from it, and build toward the car. Users have something workable from day one, and the final product responds to actual needs rather than assumptions.
Key insight
A functional skateboard in users' hands today teaches you more than a year of planning for the perfect car. Every iteration is a learning opportunity that makes the next version better.
Start small, learn fast
To move from point A to point B at every stage, accept a high-level prototype with light features: a login, a data input field, a place to see results. That's the skateboard. It's neither fast nor elegant, but it moves. Once you've learned from it, you build a scooter, then a bicycle, then a car.
Real-world feedback reveals what requirements gathering can't
Working iteratively surfaces desired features (see our article on designing M&E systems) that no blank-slate requirements session would catch. It's better to come to the table with a few core needs addressed first. Getting the minimum viable product into users' hands generates questions and desires that wouldn't emerge from a requirements document alone. This increases engagement with the product and lets us build something far more valuable.
From the field
A leading global NGO asked us to build a specific form for a single project in one country. Rather than executing this vision right away, we asked our point of contact to speak to their teams. It quickly became clear that standardized forms across a range of work would allow the product to meet the needs of all their projects and scale to the country level, and could even be adopted by partners in the same sector. Asking "could this scale?" saved the NGO from a complete overhaul later.
The pattern holds across contexts
Thinking small, acting quickly, and learning from real usage saves time, effort, and money while producing better end results. Whether you're building a KPI tracker, a beneficiary registration system, or a reporting dashboard, the principle is the same: start functional, learn from usage, iterate toward the right solution.
Watch out
The biggest risk in NGO digital projects isn't building the wrong feature. It's spending so long building the "right" one that by the time it launches, the context has changed and users have moved on to workarounds.
The antidote is speed. Get something real into users' hands quickly, even if it's imperfect, then improve based on what you learn.
Tip
Set a time limit for your first iteration: four to six weeks is a good target. If you can't get something functional into users' hands within that window, your scope is probably too broad.
At Hikaya, we help NGOs and nonprofits worldwide build digital solutions iteratively, from first skateboard to fully scaled product, so your team gets working tools at every stage.
If you're weighing how to start (or restart) a digital project without over-investing upfront, start a conversation with us. You can also see how this approach plays out in practice in our work.