Back to articles

In-house tool or Abvius | The build vs buy dilemma for NGOs | Abvius

June 8, 2026
14 min read
Marie Scotto

When it comes to structuring your NGO's financial and operational management, the temptation to "develop the tool in-house" almost always comes back to the table. A motivated IT director, a contractor developer who knows your field well, a grant budget that seems to cover the initial investment - and the idea takes hold: why pay for a licence when you can build a tailor-made tool? On paper, the saving seems obvious. In the field, eighteen months later, the figures tell a different story: deployment delays, technical debt, field teams reverting to Excel, and donor auditors asking for features that no one had anticipated.

This article reviews the four dimensions that, in practice, decide the fate of an NGO tooling project: the needs analysis, the ability to get everyone to agree (headquarters, field, donors, auditors), maintenance over time, and day-to-day support. We explain why an Abvius ERP, designed specifically for NGOs, CSOs and international solidarity organisations, wins on these four axes against in-house development - including from a financial point of view, once the full cost is put back on the table.

In-house tool vs Abvius: the true cost of a custom NGO ERP


Reading time: ~11 min

Contents:

  1. Why the "let's develop it in-house" reflex is tempting
  2. The needs analysis: the most underestimated phase
  3. Getting everyone to agree: headquarters, field, donors, auditors
  4. Maintenance: the hidden cost that derails most projects
  5. Support: what an in-house team cannot cover on its own
  6. Build vs Buy: an honest comparison table
  7. Why Abvius wins on these four dimensions
  8. Mini FAQ Build vs Buy NGO
  9. Summary and Abvius resources

1. Why the "let's develop it in-house" reflex is tempting


Three arguments come up systematically among NGOs that consider in-house development. First argument: field specificity. "Our donor constraints are unique, no off-the-shelf software is calibrated for us." Second argument: control. "An in-house tool belongs to us, we make it evolve as we want, without being subject to a vendor's roadmap." Third argument: economy. "For the price of three years' subscription, we can pay a developer for 18 months."

Each of these three arguments has an element of truth. The problem is that they systematically overlook the hidden costs: documentation, testing, security, GDPR compliance, traceability, electronic signature, multi-currency, 24/7 availability, end-user support, training of newcomers, and - above all - maintenance during the five, seven or ten years the tool will be used. Once these items are factored in, the comparison is no longer obvious at all.

2. The needs analysis: the most underestimated phase


The majority of in-house projects start from a thin set of specifications, sometimes built in two or three workshops. This is the leading cause of failure. Building an ERP for an NGO means documenting dozens of processes that no one in the organisation has ever formalised in the same place: the circulation of a field purchase order, the analytical back-allocation across four donors in the event of reallocation, the management of an advance in local currency that is settled in euros, the bank reconciliation across multiple accounts and multiple countries, the audit trail on the electronic signature of the CFO on mission.

What a thin set of specifications systematically misses

Here are the subjects that an in-house needs analysis rarely identifies before the development phase - and which then have to be dealt with urgently, often at the cost of an architecture overhaul.

  • Donor compliance: flat rates, simplified costs, eligible justifications, reporting templates for AFD, ECHO, USAID, the Global Fund, UN agencies.
  • Multi-currency and exchange rates: accounting policy, exchange gain/loss, commitment vs payment dates, cumulative variances.
  • Multi-axis analytical allocation: project, donor, country, activity, budget line, sometimes five axes simultaneously with allocation-key rules.
  • Digital audit trail: retention, time-stamping, enforceable traceability, legal duration, GDPR.
  • Validation workflows: thresholds, delegations, escalations, interim arrangements, mobility, offline field mode.
  • Data security and sovereignty: hosting, encryption, tenant isolation, business continuity plan, local compliance.

An in-house team that has never deployed an ERP in five to ten NGOs cannot anticipate these subjects. We have encountered them dozens of times and built them into Abvius from the design of the product, because our clients brought them to our attention one by one. This is precisely what is called a mature product.

3. Getting everyone to agree: headquarters, field, donors, auditors


An NGO ERP is not a tool for a single department. It must satisfy at least four stakeholders with often contradictory requirements.

The four circles of requirements

Stakeholder Priority expectation Risk if poorly covered
Headquarters - CFO, management control Real-time budget tracking, consolidation, monthly close Reverting to Excel, double entry, loss of reliability
Field - finance coordinators, logistics officers Simplicity, offline mode, mobile, local languages User rejection, parallel workarounds, loss of traceability
Donors - programme officers Templated reporting, justifications, audit trail Corrective requests, payment suspension, loss of eligibility
Auditors - internal and external Audit trail, internal controls, segregation of duties Reservations, management letters, costly recommendations

Making these four circles coexist in a single product requires trade-offs that only a vendor that has deployed at dozens of NGOs knows how to settle. An in-house development, because it is steered by the one who pays, almost always ends up optimising for just one of these stakeholders - usually headquarters - and frustrating the other three.

The classic symptom: the in-house tool works very well at headquarters, and the field keeps sending Excel tables by email. The promise of headquarters-field centralisation is never kept, and the project is judged a failure - even though the code itself works.

4. Maintenance: the hidden cost that derails most projects


This is the subject no one wants to face. Software is never finished. It has to be maintained against the wear of time: browsers that change, frameworks that become deprecated, vulnerabilities to fix, certificates to renew, dependencies to update, data to migrate. A recurring study of the software market indicates that maintenance represents between 60% and 80% of the total cost of ownership of an application over its lifespan. For an NGO, these costs cover:

  • Regulatory developments: GDPR, eIDAS 2.0, donor requirements, IATI, OHADA-SYCEBNL, HACT, IFRS for NPOs.
  • Security: system patches, penetration audits, access management, secret rotation, compliant logging.
  • Technical updates: database versions, languages, libraries, supported browsers.
  • Business developments: new donors, new countries, new currencies, new analytical rules.
  • Backups and restorations: regular testing, continuity plan, measured RPO/RTO.
  • Documentation: kept up to date with developments, accessible to newcomers, translated if needed.

The classic trap: your in-house developer or your build contractor leaves the NGO eighteen months after going into production. No one masters the code any more. The knowledge is lost. And after two years, you face a painful choice: pay a very high price for a takeover team, or replace the tool.

With Abvius, maintenance is shared across all our clients. A donor development - a new ECHO template, for example - is developed, tested, secured and deployed for everyone, at no extra cost to you. This is precisely what the SaaS model makes possible.

5. Support: what an in-house team cannot cover on its own


An NGO ERP has users all over the world, across several time zones, with very variable connection quality, uneven levels of computer literacy, and high turnover in field positions. Daily support means:

  • responding to a treasurer in Chad who cannot validate their bank reconciliation at 6 p.m. local time;
  • guiding a new DRC coordinator on entering an advance in Congolese francs;
  • unblocking a validation workflow because a signatory is on mission without a network;
  • helping the CFO prepare an export for their auditor, two days before the deadline.

In-house development rarely comes with genuine user support. The developer is not a support agent, the IT director has other priorities, and the NGO does not have the means to set up a dedicated level 1 and 2 team. As a result, questions pile up in a generic mailbox, response times explode, and users lose confidence.

On the Abvius side, support is built into the service. We design it as a product-feedback channel: every recurring question becomes a documented improvement and, where appropriate, a development of the product. Your users benefit from the questions your peers have already asked before them.

6. Build vs Buy: an honest comparison table


Here is the comparison as we present it to prospects who are still hesitating. We remain factual: an in-house tool has real advantages, which it is fair to acknowledge.

Criterion In-house development Abvius (NGO-specialised SaaS)
Field specificity 100% tailor-made, but often calibrated on a single vision Calibrated for NGOs/CSOs, enriched by dozens of field feedbacks
Time to go live 12 to 24 months, often more A few weeks to 3 months depending on complexity
Initial cost High: development, infrastructure, testing, security Controlled: subscription, configuration, onboarding support
Annual maintenance cost 60 to 80% of the total cost over the lifespan Included in the subscription, shared across clients
Donor compliance To be built and maintained for each donor AFD, ECHO, USAID, UN, Global Fund templates built in
Digital audit trail To be developed, tested and certified Native, enforceable, eIDAS and GDPR compliant
User support To be set up and funded in-house Built in, multilingual, shared field feedback
Risk of individual dependency High: departure of the key developer = project blocked Low: vendor team, contractual continuity
Regulatory evolution Your responsibility, with each change Built into the product roadmap

7. Why Abvius wins on these four dimensions


Let us explicitly revisit the four structuring axes of a Build vs Buy decision for an NGO: the needs analysis, stakeholder consensus, maintenance, and support.

Needs analysis already done - by the dozen

Abvius was born from a repeated observation among our first clients: NGOs, CSOs and international solidarity organisations share 80% of common processes and 20% of variations. We modelled those 80% in the standard product, and made the remaining 20% configurable. You do not have to redo the analysis work: it is already in the product. Your needs analysis becomes a configuration workshop of a few days, not a several-month undertaking.

Stakeholder consensus built into the product

Real-time budget tracking reassures the CFO. The electronic signature, mobile mode and multi-language interface make the tool adopted in the field. Donor reporting templates come out of the system in a few clicks, which satisfies programme officers. The digital audit trail, validation workflows and segregation of duties meet the auditors' requirements. You do not have to arbitrate between four contradictory requirements: Abvius does it for you, because we have done it for others before you.

Shared and invisible maintenance

When a donor changes a reporting template, we update it for all our clients in the same cycle. When a vulnerability appears in a library, we fix it overnight. When a new regulatory requirement emerges - eIDAS 2.0, IATI, OHADA-SYCEBNL - we build it into the roadmap. You benefit from this maintenance as an included service, without having to mobilise a technical team in-house.

Support designed for NGOs, everywhere, over time

Our support teams understand field constraints: time differences, unstable connections, turnover, multiple countries. We support your users daily, and we turn their questions into product improvements. It is this short-loop mechanism that distinguishes a specialised vendor from an in-house team, however competent it may be.

8. When in-house development can still make sense


For the sake of honesty, here are the rare cases where we acknowledge that in-house development can be justified:

  • You are a very large organisation with a mature IT team of more than twenty people, in-house product governance, and a recurring maintenance budget already ring-fenced.
  • Your use case is so singular that no off-the-shelf product covers 50% of your standard need.
  • You need deep integration into a proprietary ecosystem that vendors do not support.

Let us clarify an argument often wrongly invoked to justify in-house development: data security and sovereignty. Abvius is hosted on secure servers certified HDS (Health Data Hosting), with regular controls and audits guaranteeing the compliance, traceability and resilience required by public donors. Internalising a tool to "keep control of your data" no longer provides any security advantage - and it shifts the burden of operational maintenance onto your own teams, who rarely have the means to bear it sustainably.

Outside of these situations, which concern a minority of organisations, the economy of in-house development is almost always apparent: the extra cost reveals itself after two to three years, when it becomes impossible to turn back.

9. Mini FAQ Build vs Buy NGO


What about "vendor lock-in" with a SaaS?

A legitimate question. Our commitment: data portability through a structured export at any time, at no extra cost, in open formats. Dependence on a SaaS vendor remains measured as long as your data stays extractable. The real dependence is on a single developer who alone holds the knowledge of your in-house code.

How much should you budget for an in-house tool?

A realistic range, observed across several NGO projects: 200,000 to 600,000 euros of initial cost for a scope comparable to Abvius, then 30 to 50% of that cost per year in maintenance, hosting, security and support. Over five years, the total often exceeds 1 million euros - without the guarantee of having a product as mature as a vendor with five to ten years of field feedback.

Can you combine Abvius and in-house developments?

Yes, and it is common. Abvius exposes an API and connectors: you keep your in-house tools for the truly specific functions, and you leave Abvius the finance, operations and MEAL backbone. The best of both worlds, without paying the entry ticket twice.

What about the sovereignty of our data?

Abvius can be hosted in France on a sovereign cloud, with encryption at rest and in transit, and full GDPR compliance. Several of our NGO clients operate with AFD, MEAE and European donor requirements: sovereignty is not a marketing promise, it is a contractual parameter.

10. Summary and Abvius resources


The choice between in-house development and a specialised ERP like Abvius is not an ideological choice. It is a financial and operational decision that is settled on four axes: the quality of the needs analysis, the ability to bring headquarters, field, donors and auditors into alignment, the real cost of maintenance over time, and the robustness of day-to-day support. On these four axes, Abvius offers dozens of field feedbacks already built in, a product that naturally reconciles stakeholders, shared maintenance and NGO-specialised support. We are not saying that in-house development is always a bad idea - we are saying that you must, knowingly, put the full figures on the table before deciding.

To go further, we recommend:

To discuss your case - needs analysis, scope, donor constraints - get in touch via abvius.org.