Crisis fundraising does not wait for your vendor's roadmap.
Our CEO recently argued in Forbes that AI has changed the build vs buy equation. I have seen that play out firsthand. We built UNHCR's global donation platform, and the decision behind it tells a more specific story about what happens when "buy" stops working for organizations where speed is a governance problem, not a design problem.
$67M+Processed
35+Markets
2,500+Campaigns
15mLaunch Time
As of December 2025, that platform has processed US$67M+ across 35+ markets, with campaign launch times down to 15 minutes. Here is what drove those decisions and what they mean if you are facing the same ones.
Why NGOs keep hitting this wall
Most donation SaaS tools work fine in steady state. Then an earthquake hits. Or a conflict escalates. Or a funding appeal needs to go live across 12 markets in 3 languages by tomorrow morning. And "simple" becomes "please file a support ticket and we will get back to you within 48 hours."
SaaS tools cover 70 to 80 percent of what most organizations need, and the maintenance burden you avoid usually justifies the features you give up. That math checks out for most businesses. For humanitarian organizations, the missing 20 to 30 percent is where the crisis response lives.
UNHCR supports over 117 million forcibly displaced people worldwide. When a crisis breaks, the fundraising response has to move at the speed of the news cycle, not the speed of a vendor's sprint backlog.
The penalty for being slow is not a missed quarterly target. It is reputational damage at the exact moment the world is watching. This is the heart of the crisis fundraising gap and why speed matters in modern global operations.
What pushed UNHCR to build
UNHCR's problem was not that their tools were bad. It was that global fundraising at their scale requires speed and governance across markets. Not one or the other. Both, at the same time, under pressure.
Before the platform, they had scattered campaign pages across multiple markets. Each with its own setup. Inconsistent donor experiences. Uneven reporting. Different security postures. Wasted effort on every rollout. Fragmentation was the real enemy. Not SaaS.
So they partnered with us to build a Drupal-based global donations platform designed for one thing: repeatable speed with centralized governance. The results are detailed in our UNHCR case study, capturing the impact as of December 2025.
Fifteen minutes. Not because someone pulled an all-nighter. Because the system was designed so campaign teams can clone a high-performing campaign, update the content, select a layout, configure the local payment methods, and publish. No code. No ticket. No waiting for engineering. That is what build looks like when it is done right: repeatable workflows that non-technical teams can operate under pressure.
What "ownership" actually meant in practice
- Speed without dependency: UNHCR's campaign teams publish using reusable templates and Layout Builder. They create campaigns themselves.
- Governance that scales: A Global Admin keeps full visibility from a single dashboard. Adding a new market is configuration, not a rebuild.
- Data control: Salesforce sync and Google Analytics Enhanced Ecommerce are connected to the core. This secures data sovereignty and the own vs rent decision.
- Verified security: Transaction-level logging and a partnership with Upsun for 99.99% uptime ensure quick deploys during crisis.
Where AI helps (and where it doesn't)
AI has compressed development cycles. A controlled experiment with GitHub Copilot found that developers with AI assistance completed coding tasks 55.8 percent faster. The effect is real and measurable.
But AI speeds up the building. It does not speed up the thinking. No AI tool designs your market governance model or determines who gets access to what across 35 markets. These are human decisions requiring judgment and context.
Dependency and component risk does not shrink. OWASP's Top 10 calls out vulnerable components as a top application risk. NIST's Secure Software Development Framework (SP 800-218) lays out practices for cutting vulnerability risk that your team must manage, not the AI. Furthermore, donation platform fees and hidden costs still apply regardless of development speed. AI shifts the economics: it works best inside a system that already has discipline around governance and security.
Should you build? A quick diagnostic.
If you answer "yes" to three or more of these, it is time to seriously look at owning the platform.
✓
Do urgent appeals need vendor help or long lead times to launch? If your first call is to a SaaS provider, that is a problem.
✓
Do markets need different payment methods that your current tool struggles with? Rigidity costs you market share.
✓
Are you paying extra for features that feel basic like localization? For a global nonprofit, these are table stakes.
✓
Can you export donor data cleanly? If not, you have a data ownership problem hiding in plain sight.
✓
Can you get straight answers to security questions worth asking? Marketing answers are a red flag.
✓
Does leadership need consistent reporting? Each market being an island creates stacking risks.
One critical qualifier: build the core platform once. Scale by configuration. That is the blueprint UNHCR followed. It is how they went from 9 markets to 35+ without rebuilding the foundation.
Where to go from here
For NGOs, the build vs buy question was never purely about code. It is about control. When a crisis breaks, you need to publish a campaign in 15 minutes, not petition a vendor for a feature. The teams that figure this out early will have a real edge when the next emergency hits and the world is watching.
