01 · What breaks
Design for the failure modes, not only the happy path.
Most MIS budgets go wrong before a line of code is written, because the estimate counted screens and left out the work around them.
Estimating before workflow discovery
A quote given after one call prices the organisation's description, not its workflow. Ask for sample sheets, forms and the reports funders actually request first. Discovery that costs a few days is cheaper than a fixed price built on guesses, followed by change requests.
Licences confused with implementation
Licences are a recurring cost per user or per app; implementation is a one-time cost for design, build, testing and training. Compare both over three years, and check nonprofit pricing before you assume a platform is out of reach. EdZola's Zoho for nonprofits page explains the discount route.
Data cleaning omitted
Five years of donor-wise spreadsheets usually contain the same participant three times, three spellings of one village and dates in four formats. Cleaning and mapping that history is real work. Estimate it separately, and decide which history is worth migrating at all.
Support and internal ownership treated as free
Someone inside the organisation must approve changes, train new staff and answer the field team's questions after the partner leaves. If that time is not budgeted, the system drifts back to Excel within a year. Count an internal owner's hours as part of the cost.
02 · Minimum viable model
Estimate from counts you can check, then add the costs nobody demos.
These six inputs explain most of the difference between a small and a large build. Fill each in from real artefacts, not from memory, and record the assumption behind every number.
Hypercare
The first 30 to 45 days after go-live bring the real questions. Budget fixes, small reconfigurations and weekly adoption reviews for that period.
Role-wise training
Field staff, managers and administrators need different sessions and guides. One generic demo is not training.
Change requests
Anything outside the signed design is priced separately. Agree the rule for bugs versus changes before the build starts.
Annual support
Platform updates, new funder formats and staff turnover create steady small work. Plan a support arrangement, not ad hoc favours.
03 · Implementation sequence
Move through reviewable gates.
Work through the estimate in this order. Each step narrows the range and makes the remaining uncertainty visible to whoever approves the budget.
Describe one complete workflow
Write down one journey end to end, for example enquiry to enrolment to attendance to assessment to follow-up, with who does each step and where it is recorded today. Mark every step done in WhatsApp, email or paper. Those steps are where hidden scope lives.
Count roles and exceptions
List each role and what it may create, view, edit, approve or export. Then list the exceptions: transfers, re-enrolments, backdated entries, partner access. Exceptions and approvals, not the number of forms, are what push a build from small to medium.
Profile migration and integrations
Count records, sheets and years of history, and test a sample for duplicates and missing IDs. For each integration, note what syncs, in which direction and how often, for example accounting codes into the programme system. Untested integrations are where late surprises hide.
Separate launch from ongoing cost
Split one-time set-up cost (design, build, migration, training) from recurring cost (licences, hosting, support, messaging fees where WhatsApp or voice is used). Funders often fund the set-up from a programme grant; the recurring line needs a home in core or M&E budgets.
State assumptions and exclusions
Write what the price includes and excludes: number of modules, forms, roles, reports and integrations; languages; offline use; who cleans the data. A fixed-outcome first phase works only when this list is explicit and signed, with changes priced separately after sign-off.
Review range with implementation teams
Show the range and its assumptions to the people who will build and run it. Ask which assumption, if wrong, moves the cost most. Where budget is tight, cut scope into phases rather than cutting testing or training; a cheaper go-live that nobody adopts is the most expensive option.
04 · Evidence
Measure whether the work became clearer.
An estimate earns trust when, after go-live, you can compare it with what actually happened and explain every difference.
Many funders cap administrative costs, so a standalone "IT" line is the first one cut. Present the MIS as part of monitoring, evaluation and programme delivery, phased so each phase fits one grant cycle and remains useful on its own.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Turning counts into a small, medium or large band
- Showing which drivers widen the range
- Separating set-up and recurring cost
- Comparing the estimate with actuals after go-live
People should decide
- Budget approval
- Risk appetite
- Scope trade-offs
- Vendor and platform choice
06 · Common questions
Practical questions teams ask.
The cost questions finance leads, programme heads and boards raise before approving a data system.
How much does a nonprofit MIS cost?
It depends on counts more than on organisation size: how many modules, forms, roles, workflows, reports and integrations, whether it must work offline, and how much messy history must be migrated. A single-programme system with a few roles sits in a very different band from a multi-state system with partner access. Ask any partner to show the counts behind their price.
What costs are usually left out of an MIS budget?
Data cleaning, role-wise training, the month of support after go-live, change requests after the design is signed, recurring licences and messaging fees, and the time of an internal owner. Each is small on its own, but together they decide whether the system is still used a year later.
Is a fixed-price MIS quote better than paying by the hour?
A fixed price for a clearly defined first phase protects both sides, provided the inclusions are written down and signed: modules, forms, roles, reports, integrations and languages. Work outside that list is then priced as a change. Hourly billing suits open-ended support better than a new build.
How can a small NGO keep MIS costs down?
Start with the one workflow that hurts most, use a low-code platform with nonprofit pricing, reuse standard building blocks such as participant, session, attendance and assessment, and migrate only the history you will actually use. Spreading the build across grant cycles in phases is safer than squeezing testing or training.
How should we check whether an MIS estimate was accurate?
After go-live, compare the estimated counts and assumptions with what was built and what changed. Note which driver caused each difference: late inputs, new reports, extra roles or dirty data. That review makes your next estimate, and your next conversation with a funder, much more credible.