01 · What breaks
Design for the failure modes, not only the happy path.
Buying decisions go wrong when the comparison is between demonstrations rather than between operating realities. These four mistakes account for most regretted choices we see.
Buying on a polished demo
A demonstration shows the vendor's best journey with clean sample data. Ask every option to run your representative case, with your exception, a restricted role and a report whose denominator you can check. Score what you saw, not what was promised for a later release.
Calling configuration free
Configuring an off-the-shelf product still takes design, testing, migration and training; only the coding is saved. Ask who does that work, how long it takes and what it costs. A product that is cheap to license and slow to fit can cost more than a configured build.
Ignoring adoption and migration
Every option needs clean data and staff who change habits. If the comparison ignores migration and adoption, the option that looks fastest wins and then stalls. Count the history you must move and the people who must change how they work.
Customising around a broken process
Customising software around a process nobody has agreed simply makes the confusion permanent. Settle the workflow, definitions and owners first. As EdZola's field guide on technology's three jobs puts it, automating a confused workflow gives you a confused workflow at scale.
02 · Minimum viable model
Record the decision so it can be explained a year later.
Keep one decision record for the comparison. These six entries make the trade-offs explicit and give the next leadership team a reason, not just a vendor name.
| Option | Usually fits when | Watch for |
|---|---|---|
| Off-the-shelf product | The workflow is common (donor CRM, HR, accounting) and you can adopt its model | Workarounds for programme-specific journeys; per-user licence growth |
| Open-source sector platform | A platform already models your work, such as Avni for field data or Glific for WhatsApp, both stewarded by Project Tech4Dev | Hosting, support and training still need a budget and an owner |
| Configured low-code | Journeys, relationships or permissions are distinctive but follow known patterns | Release discipline and an internal owner, or it drifts |
| Fully custom code | Scale, integration or performance needs exceed what platforms allow | Long build, single-developer dependence, higher maintenance |
03 · Implementation sequence
Move through reviewable gates.
Run the comparison as a short, structured exercise. Each step produces evidence you can show a board or funder.
Document the current and desired workflow
Draw the entities before the screens: participant, session, assessment, follow-up, or donor, pledge, receipt. Note the relationships that matter, such as one person in several projects. This drawing usually shows whether you are buying a CRM, an MIS or both.
Separate must-haves from preferences
Separate must-haves, each tied to a named decision or obligation, from preferences. Most nonprofit systems share a large standard core (registration, attendance, assessment, follow-up); the programme-specific part is smaller than it feels. Spend comparison time on that part.
Test one real journey in each option
Give each shortlisted option the same representative case, the same restricted role and the same report, and ask them to show it working. A partner that will not model your case before contract is telling you how the project will go.
Estimate three-year ownership
Add licences, implementation, migration, training, hosting, support and internal staff time over three years. Include messaging or voice costs if the option relies on them. Free licences are not free if your team pays in workarounds and maintenance.
Check export and exit terms
Confirm you can export all records and attachments in a usable format, who owns the data and the configuration, and what happens to both if the contract ends. Under India's data protection law your organisation remains responsible for personal data, whichever vendor processes it.
Record the decision and assumptions
Write down the choice, the scores, the assumptions and the risks accepted, and set a date to review them after go-live. If the reasons are recorded, the next team can change course deliberately instead of starting over.
04 · Evidence
Measure whether the work became clearer.
A good choice is visible within a few months: the critical journey runs without workarounds, and the team can change a form or report without waiting on a developer.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Scoring options against weighted requirements
- Modelling three-year cost scenarios
- Testing export and data portability
- Keeping the decision record and its assumptions
People should decide
- Weighting requirements
- Accepting trade-offs
- Choosing procurement risk
- Approving the final platform
06 · Common questions
Practical questions teams ask.
The questions boards, executive directors and programme heads ask when choosing between a product and a build.
When should a nonprofit choose a custom MIS instead of off-the-shelf software?
Choose a custom or configured MIS when the programme's journeys, relationships, permissions or reporting logic are distinctive and central to delivery, for example case management with restricted notes, or participants moving across projects and funders. Choose a product when the work is common, such as donor management or payroll, and your team can adopt the product's model without daily workarounds.
How do custom and off-the-shelf systems compare on cost and implementation effort?
Off-the-shelf products usually cost less to start but carry per-user licences and configuration work that buyers underestimate. Configured low-code builds cost more upfront in design and testing but fit the programme closely. Fully custom code costs most to build and maintain. Compare all three on a three-year view that includes migration, training and internal staff time.
How do custom and off-the-shelf systems compare on field work, reporting and permissions?
Products are strongest where their model matches yours and weakest at offline field use in local languages, programme-specific reports and fine-grained access, such as a counsellor seeing only their own cases. Configured systems handle those well if they are designed and tested deliberately. Ask each option to show your hardest permission rule working.
Which ownership and exit trade-offs are easy to miss?
Check whether you can export every record and attachment in a usable format, who owns the configuration and any custom code, how much depends on one developer's knowledge, and what happens to hosting and support if the contract ends. Also check that your internal administrator can make routine changes without the vendor.
When should a nonprofit replace its current software approach?
Consider replacing it when critical workflows depend on repeated workarounds, permissions cannot be enforced, reports need manual reconstruction every month, or the current tool cannot support a new programme model. Before replacing anything, check whether the real problem is an unclear process. A new tool will not fix three overlapping spreadsheets on its own.