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 can end up with solutions better adapted to actual user needs and constraints, and can save time and money along the way.
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 can reveal user needs that may not surface from blank-slate requirements gathering
- Asking deeper questions early (like "could this scale to other projects?") can save significant rework later
- This approach breaks from traditional NGO project management logic but tends to lead 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 gives you real feedback early. Every iteration is a learning opportunity that informs the next version.
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 can surface desired features (see our article on designing M&E systems) that a blank-slate requirements session might miss. It's better to come to the table with a few core needs addressed first. Getting the minimum viable product into users' hands can generate questions and desires that may not emerge from a requirements document alone. This can increase engagement with the product and lets us build something better suited to users' needs.
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?" helped the NGO avoid a complete overhaul later.
The pattern holds across contexts
Thinking small, acting quickly, and learning from real usage can save time, effort, and money, and tends to produce 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
One risk in NGO digital projects is spending so long building the "right" feature that by the time it launches, the context has changed and users have moved on to workarounds.
One way to reduce that risk is speed. Get something real into users' hands quickly, even if it's imperfect, then improve based on what you learn. The same staged logic applies to AI adoption at NGOs: start with chatbot fluency, build context, then automate, rather than jumping to agentic workflows on day one.
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.
