Build vs. Buy Decisions for Nonprofit Internal Tools

The nonprofit technology budget reality: what organizations have to work with

Every dollar a nonprofit puts into software is a dollar that didn't go to a case manager's salary or a meal program's grocery bill. That tradeoff, not which platform has the nicer dashboard, is the real subject of any build vs. buy decision inside a mission-driven organization. Standard tech advice assumes an engineering team on staff, capital to absorb a multi-year cost curve, and growth that justifies the investment. None of that holds for most nonprofits. Process fit, ownership of the thing after it ships, and continued operation three years from now with the same three-person staff that exists today are what actually decide the question.

Spending patterns split hard by size. Figures that circulate in NTEN's guidance put small nonprofit tech spend around 13.2% of the overall budget, while larger organizations spend closer to 2.8%. Those numbers are dated, so treat them as a rough shape rather than a current snapshot. Other planning guidance suggests a working range of three to six percent of annual operating budget, though that figure should be confirmed against current sources.

Spend isn't the real problem, though. Use is. Available figures suggest 89% of nonprofits don't get full value out of what they've already bought, and only a small share count as digitally mature, even though a large majority say digital transformation is essential to their work. That gap between what people believe and what they actually run day to day is the whole story in miniature.

A significant share of the average nonprofit IT budget gets wasted on tools nobody uses: subscriptions nobody remembers signing up for, licenses sitting idle. That waste is structural, and it lines up with what's happening in for-profit software too. Zylo's SaaS Management Index found organizations use just 54.4% of the licenses they pay for, with the average company losing $19.8 million a year to idle seats. Nonprofits run the same math at a much smaller scale, with far less room to absorb the loss.

So the question a nonprofit is actually answering is narrower than "what's the best tool on the market."" It's narrower: what can staff actually operate and keep alive without a dedicated IT hire? That reframe changes almost every decision downstream of it.

Capacity-building grants increasingly treat technology as an eligible expense, and a funder is far more likely to approve a line item described as "workflow automation for case management" than one that just says "IT expenses." Specificity reads as mission alignment. Vagueness reads as overhead.

The seven criteria that settle a nonprofit's build vs. buy question

Standard build vs. buy frameworks lean on seven factors: strategic differentiation, regulatory or compliance burden, internal engineering capability, integration density, multi-year total cost of ownership, urgency, and governance fit. For a nonprofit, the weight on two or three of these shifts hard enough to flip the whole answer, and engineering capability is the one that flips it fastest.

Most nonprofits have zero engineers on payroll. That single fact rules out a pure custom build unless a long-term technical partner is already in the picture, and it changes the maintenance math for every path under consideration, not just building.

Governance complexity is a direct cost, paid in staff hours nobody has. A program director who's also running donor outreach and managing a grant report can't spend three hours a week fighting a badly configured SaaS tool. So governance caps how much time and attention a tool is allowed to eat before it starts undermining the work it was supposed to support.

Urgency cuts both ways. Grant cycles and reporting deadlines create real pressure to move fast, and that same pressure is how nonprofits end up adopting a tool nobody fully understands and nobody can maintain past the deadline that forced the decision.

Total cost of ownership plays out differently on each path. Buying compounds over time through seat growth, tier upgrades, usage-based pricing, and integration costs that creep in as the org adds systems. Building front-loads the cost, then flattens into an annual maintenance bill. Neither path is cheaper as a rule. Where the lines cross depends on how long the tool needs to live and how much staff attention is available to keep it running.

Data ownership deserves its own line, and it gets skipped more than it should. Donor records, client files, grant reporting data: these often carry confidentiality obligations that aren't optional. A breach can run into six figures once notification costs, forensics, and remediation are added up, which dwarfs years of basic security spend.

Two diagnostic questions cut through this faster than the seven-factor list does. A useful diagnostic: would a peer organization running the identical tool actually hurt the mission's delivery? If the honest answer is no, buying is the default, full stop. The second question matters just as much: does the off-the-shelf tool fit the actual process, or does staff end up bending the process to fit the tool? The real hidden cost of buying is rarely the subscription line. It's the pile of manual workarounds built around a tool that almost does the job.

A third path belongs in this conversation, and most frameworks skip it entirely: buy-and-extend. A purchased platform, stretched with APIs or low-code automation tools, often gives a nonprofit more control than rigid SaaS and a lighter maintenance load than a full custom build. For an org with an unusual workflow but no engineer on staff, this is frequently the answer that actually works, and it should be the first thing evaluated.

The hidden total cost of ownership on each path

Build costs appear in places that never make the first invoice: the monthly cloud bill raises ongoing expense, the hours someone spends patching and maintaining code consume staff time, the opportunity cost is visible when a staffer's attention goes to the tool instead of the program, and eventually the rewrite becomes necessary once the original codebase can't stretch any further.

Buy costs hide differently. Implementation fees that weren't in the original quote. Renewal prices that jump after year one. Usage-based charges tied to AI or data features. Integration work, plus admin overhead that lands on whoever's already stretched thinnest. Research consistently finds that a large share of organizations hit unexpected costs after signing a SaaS contract, often paying extra for AI or consumption-based features they hadn't budgeted for.

There are rough benchmarks for the build side too. Maintenance on a custom build typically runs 15% to 25% of the original development cost every year, with McKinsey putting the figure around 20% annually. A $20,000 internal tool carries roughly $3,000 to $4,000 a year in upkeep, whether or not anyone's actually assigned to own it. That cost sits on the calendar regardless of staffing.

Buying has its own version of the rug-pull. SaaS consolidation has accelerated, with acquisitions, rebrands, and shutdowns running at a high pace in recent years. Tools get bought, rebranded, repriced, sometimes shut down outright, and a nonprofit that's wired a tool deep into daily operations pays the migration cost when that happens, on a timeline it didn't choose.

Building carries its own well-documented pattern of underestimation. Research from McKinsey and Oxford, looking at more than 5,400 IT projects, found large projects run 45% over budget on average while delivering 56% less value than projected. Nonprofit builds run smaller, but the instinct to underestimate scope and long-term maintenance occurs regardless of scale.

Neither path is safe by default. A specific organization, with its specific staff and governance structure, has to manage a specific set of risks. Which set it can actually handle is what decides the answer, not which path looks cheaper on a spreadsheet in month one.

Technical debt as a mission problem, not just a technology problem

Technical debt is a predictable stage: a tool built for one scale of work gets pushed to handle more, without the engineering time to keep pace.

A useful distinction separates two kinds. Intentional debt, sometimes called design debt, is the deliberate choice to move fast now and clean up later. That's recoverable, as long as it's documented and someone's actually planning to come back for it. Unintentional debt is the harder one. It builds up from rushed implementation, miscommunication between whoever commissioned the tool and whoever built it, or integrations nobody fully understood at the time, and it stays invisible until something breaks.

Arcstone's work with nonprofit technology describes a "house of cards" pattern that's easy to recognize once named: features keep getting bolted onto an aging system, and over time the whole stack turns slow, brittle, confusing to anyone new. Sunk-cost thinking keeps organizations holding onto systems that already cost more to maintain than they'd cost to replace. That's its own quiet failure mode.

There's a security dimension too. Unpatched systems and legacy integrations create security exposure that puts sensitive data at risk. Technical debt functions as a compounding drag on mission delivery, and that cost is rarely visible until something breaks.

A practical starting move any nonprofit can take without hiring a consultant: inventory every platform, tool, and customization currently running. Write down the manual workarounds, the unsupported plugins, the duplicate data nobody's cleaned up, the slow spots everyone's just learned to live with. Debt stays hidden until someone writes it down, and writing it down is the actual prerequisite to fixing anything, not a nice-to-have step before the real work starts.

Available estimates suggest around a third of development time goes to maintenance and technical debt, and that share grows every time a new custom tool gets built without a clear owner assigned. For a nonprofit running on volunteer-built or AI-generated tools, that cost stays unpaid until something breaks, or it lands on program staff who never signed up to debug a database.

That's the real stake here. A single broken workflow in a donor database, a grant reporting tool, or a client intake form turns into a missed report, a delayed service, a program that doesn't run on time.

What "building" costs a nonprofit in 2026, and what commonly gets left out of that estimate

Most nonprofit internal tools are at the simpler end of the scope spectrum, and 2026 cost data reflects that. Basic web apps or MVPs, with minimal feature sets and no serious scaling pressure, run somewhere between $5,000 and $20,000. Custom apps with real dashboards, CMS integration, or tailored workflow logic run $18,000 to $50,000.

Tools like Cursor, Claude Code, and GitHub Copilot have compressed the upfront build time on internal dashboards and integration glue from months down to days in some cases. That's only half the story, though. What hasn't moved is the tail end. Emerging analysis of AI-assisted codebases has found that copy-pasted code is outpacing refactored code, a pattern that signals growing maintenance burden. That's a signal that AI-assisted speed produces code that's harder to maintain once it's out in the world, not easier.

An AI-built prototype makes it to production with nobody assigned to keep it alive afterward more often than anyone wants to admit. Speed at the start buys nothing for the years a tool has to keep running after launch.

What routinely gets left off the estimate: the ongoing cloud bill, staff time spent on admin and upkeep, integration maintenance whenever an upstream system changes its API, and the eventual rewrite once the code can't be patched forward any further.

There's a sharper cautionary number for orgs tempted to skip validation and build the full thing at once. Research on full product builds without phased testing puts the average cost around $800,000, with a 72% failure rate, and 67% of those failures traced back to building something nobody actually wanted, not to bad code. A nonprofit commissioning a full custom system without validating the workflow first runs the same risk on a much smaller budget. That doesn't make it a smaller mistake.

None of this contradicts the demand for internal tools. WeWeb's internal tools guide found 86% of organizations plan to maintain or grow their internal tools spend. That's genuine appetite, not blind confidence in the economics, and it comes paired with real surprise on the invoice once the maintenance bill actually arrives.

The engineering partner options nonprofits have, and what each delivers

Three structural models exist for getting a tool built, and each comes with a different ceiling. A low ceiling forces a costly rebuild later, while a higher one avoids that rebuild.

Pro bono volunteer programs cost nothing upfront, but the ceiling appears fast in what most of them deliver: a working foundation, not a maintained production system. Opportunity Hack, a 501(c)(3) running since 2013, has mobilized more than 3,000 volunteer developers to build free tools (volunteer scheduling systems, donor databases, impact dashboards) for over 200 nonprofits. Its weekend hackathons pair with a Founding Engineer model that keeps one or two engineers on a project after the hackathon ends, deploying it to production and training staff on it. That's a direct fix for the most common failure mode in volunteer tech work: the beautifully scoped project that dies the moment the hackathon demo ends. Taproot Foundation's Taproot Plus lets nonprofits fully customize a pro bono request, covering software engineering and web development. Develop for Good recruits and manages teams of college students on design and development projects, including websites and mobile apps. Unless an ongoing structure gets built in from the start, someone still has to own what happens after the volunteers move on, and that someone is usually a staffer with no engineering background.

Corporate pro bono programs run on similar logic at bigger scale. Morgan Stanley's Tech Change Makers program runs six-to-eight-month engagements pairing Morgan Stanley technologists directly with nonprofits. The 2025 cohort supported more than 30 organizations on websites, apps, and workflow tools, with applications for 2026 open. Salesforce's pro bono program has delivered 700,000 volunteer hours and $128 million in value at no cost to nonprofit partners, mostly centered on Salesforce ecosystem tools and configuration. These programs are competitive to get into, run in cohorts, and scoped to a defined deliverable rather than an open-ended technical relationship.

Mission-aligned product engineering studios sit at the other end, and this is the option most nonprofits underrate. They cost money, but they're structured for the long haul, filling the gap the free models can't reach by design. Who owns the tool once the engagement wraps? Who watches production reliability, updates dependencies before they break something, answers the phone when a tool fails mid-grant-report? A studio that treats a nonprofit's mission as the actual client offers what the volunteer models structurally can't: a technical partner that sticks around through the maintenance years, including after the build. For a nonprofit weighing paid options, the actual need is a partner who owns the engineering work so program staff can go back to running programs instead of firefighting a broken tool. Screen for a partner who understands the operating constraints (tight budgets, mission-first tradeoffs, staff wearing three job titles at once), who prices in a way that doesn't reward scope creep, and who treats technical debt as a known, plannable stage rather than a surprise on next quarter's bill.

When buying is the right answer

Buying is the right call whenever the tool in question isn't part of what makes the organization's work distinct, and for most nonprofits, that's most of the software stack. Run the diagnostic from earlier: would a peer nonprofit using the exact same platform actually hurt this org's mission delivery? For most back-office and infrastructure categories, the honest answer is no. That makes buying the default rather than the exception, not a compromise to feel bad about.

Donor management and CRM platforms are the clearest case. The workflows (tracking gifts, managing pledges, running appeals) are close enough across nonprofits that a shared platform, configured well, beats a custom build almost every time. Accounting and financial reporting tools fall in the same bucket: the compliance requirements are standardized enough that buying gets an organization audited-and-reportable faster than building ever would.

Email marketing and communications tools, volunteer scheduling, basic case management for common program types, HR and payroll: these solve problems shared across the whole sector, not unique to any one org's mission. Building any of them from scratch means spending scarce engineering attention on a problem that's already been solved, repeatedly, by vendors who update and secure the product on someone else's payroll.

The buy default breaks down only when a nonprofit's actual workflow doesn't map onto what the market builds for. A food bank tracking inventory across a specific mix of cold storage, mobile pantries, and partner agency pickups might find every off-the-shelf inventory tool assumes a retail model that doesn't fit its operation. That's the signal for buy-and-extend: keep the platform, wire in what's missing through an API or a low-code layer, and skip the trap of bending an entire program's operations around software that almost, but doesn't quite, work.