01 · What breaks
Design for the failure modes, not only the happy path.
The value of custom MIS versus off-the-shelf NGO software depends on what happens when records are incomplete, evidence conflicts or the next action carries consequence.
Buying on a polished demo
Make this visible in testing, ownership and review rather than leaving it as an implementation surprise.
Calling configuration free
Make this visible in testing, ownership and review rather than leaving it as an implementation surprise.
Ignoring adoption and migration
Make this visible in testing, ownership and review rather than leaving it as an implementation surprise.
Customising around a broken process
Make this visible in testing, ownership and review rather than leaving it as an implementation surprise.
02 · Minimum viable model
Start with decision record with weighted requirements and the decisions around it.
The smallest useful model for this page connects the following records. Each field should have a purpose, owner and retention rule.
03 · Implementation sequence
Move through reviewable gates.
A complete small workflow is safer and more useful than a large collection of unfinished modules.
Document the current and desired workflow
Agree the owner, evidence and exit condition before moving forward.
Separate must-haves from preferences
Agree the owner, evidence and exit condition before moving forward.
Test one real journey in each option
Agree the owner, evidence and exit condition before moving forward.
Estimate three-year ownership
Agree the owner, evidence and exit condition before moving forward.
Check export and exit terms
Agree the owner, evidence and exit condition before moving forward.
Record the decision and assumptions
Agree the owner, evidence and exit condition before moving forward.
04 · Evidence
Measure whether the work became clearer.
Usage alone is not success. Review the quality, timeliness and decisions the system is meant to improve.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Separate must-haves from preferences
- Test one real journey in each option
- Estimate three-year ownership
- Check export and exit terms
People should decide
- Weighting requirements
- Accepting trade-offs
- Choosing procurement risk
- Approving the final platform
06 · Common questions
Practical questions teams ask.
Use these answers to clarify scope, compare approaches and identify the decisions your team needs to make before implementation.
When should a nonprofit choose a custom MIS instead of off-the-shelf software?
Off-the-shelf software is usually stronger when the workflow is common and the organisation can adopt its model. A custom or low-code MIS is stronger when distinctive journeys, relationships, permissions or reporting logic are central to delivery. The decision should include implementation and long-term ownership.
How do custom and off-the-shelf systems compare on cost and implementation effort?
The main cost and timeline drivers are workflow and permission complexity, data migration quality, integrations, offline or language needs, testing availability, training and long-term ownership. Estimate after modelling one real journey and its exceptions.
How do custom and off-the-shelf systems compare on field work, reporting and permissions?
Off-the-shelf software is usually stronger when the workflow is common and the organisation can adopt its model. A custom or low-code MIS is stronger when distinctive journeys, relationships, permissions or reporting logic are central to delivery. The decision should include implementation and long-term ownership.
Which ownership and exit trade-offs are easy to miss?
The main risks are buying on a polished demo, calling configuration free, ignoring adoption and migration and customising around a broken process. Test these with representative cases and keep the consequential judgement with a named person.
When should a nonprofit replace its current software approach?
Consider switching when critical workflows depend on repeated workarounds, permissions cannot be enforced, reporting requires manual reconstruction or the current platform cannot be maintained responsibly. Test the replacement against a complete real journey before migrating.