How we move donor records, giving history, and campaign data off the major platforms — and the CLI tooling we built to make it clean.
Chris Hanson spent over a decade at Barbells for Boobs, a nonprofit that raised more than $25 million for breast cancer screening. During that time the organization moved through multiple fundraising platforms. He was a reference client at Classy during its formative years, a design consultant to Funraise working directly with their nonprofit clients, and a recurring voice in each platform's community. This is what that experience actually looked like, and what it eventually made clear.
Nonprofit platform churn is one of the most consistently underreported problems in the sector. Platforms advertise their client lists. They do not publish their departure rates. If they did, the industry would look very different from the one they present on their marketing pages.
The roster that nobody audits
Go to the homepage of any major nonprofit fundraising platform and you will find a grid of logos. Organizations you recognize. Names that signal credibility. The implicit message is clear: these organizations chose us, and that choice validates everything we're telling you.
What that logo grid doesn't tell you is how many of those organizations are still active clients. It doesn't tell you how many left after two years because they hit a ceiling the platform couldn't raise. It doesn't tell you how many are listed because they used the platform once for a single campaign five years ago and the platform never removed them. And it definitely doesn't tell you how many of those same logos appear on three or four competitor platforms simultaneously, because the organization tried all of them looking for something none of them fully delivered.
I know this from the inside. I spent more than a decade at Barbells for Boobs, a nonprofit that raised over $25 million funding breast cancer screening for uninsured and underinsured women. During that time we moved through multiple platforms. I was not a passive user of any of them. I was inside the product conversations, consulting on design decisions, talking to their prospective clients, appearing on their podcasts. I believed in what each of these platforms was trying to do. And I still found the ceiling on every one of them.
What the involvement actually looked like
The first platform we used was a company called Fundraise. It handled the basics of peer-to-peer fundraising for what the technology was at the time. When we reached the limits of what it could do, we moved to Classy during its early period, before the GoFundMe acquisition, when the product was still being actively shaped by feedback from its nonprofit community.
Our team was not a passive presence during those years at Classy. We provided ongoing directional product feedback. I served as a reference client, speaking independently with prospective nonprofit customers about our experience on the platform. When Classy was developing their Salesforce integration, I was in those conversations providing input from the perspective of an organization running the integration in production and living with the consequences of every architectural decision it made. That is a specific kind of involvement that goes well beyond being a satisfied customer leaving a review.
When we eventually moved to Funraise, the relationship went deeper still. I was a consultant to their design teams, working directly with their nonprofit clients to build custom campaign experiences. One of the projects I worked on was a dedicated campaign page for Dressember, building out the custom fundraising experience for their annual initiative. I was also on the Funraise podcast talking about how Barbells for Boobs used the platform, the customizations we had built to make our campaigns work the way we needed them to, and how we had extended the platform beyond its defaults to make it dynamic enough for what we were doing.
That level of involvement is worth naming plainly: I was not just a customer evangelizing a product I liked. I was a practitioner helping the platform's team understand what serious nonprofit fundraising programs actually need, and helping their other clients get more out of the platform than its out-of-the-box configuration would deliver. The work I did for Dressember's campaign was the kind of custom build that required going around the platform's template system rather than through it, which is itself a signal worth paying attention to in retrospect.
I was not just a customer evangelizing a product I liked. I was a practitioner helping platforms understand what serious nonprofit fundraising programs actually need — and still finding the ceiling.
What the ceiling feels like from the inside
Platform ceilings don't usually announce themselves. They accumulate. A campaign mechanic you need that doesn't exist in the template library. A registration flow that requires a workaround because the platform's model assumes a simpler structure than your event actually has. A Salesforce sync that works for standard donation records but breaks on edge cases your organization generates regularly because of how your programs are structured. A campaign page that is constrained by the platform's visual system in ways that make it impossible to carry your brand identity the way your mission deserves.
Each of these is a small thing individually. Together they define the outer boundary of what your fundraising program can be on that platform. You spend organizational energy navigating constraints rather than building campaigns. Your team becomes expert at workarounds rather than strategy. The platform that was supposed to enable your growth becomes the thing your growth has to route around.
The Dressember campaign work at Funraise is a useful example of this pattern. Building a custom campaign experience for a nonprofit with a distinctive fundraising model — one that didn't fit cleanly into the platform's standard P2P template — required going around the template system rather than through it. The work got done. The campaign performed. But the effort required to make it happen was disproportionate to what the output looked like from the outside. The platform's constraints were invisible to the campaign's participants and visible to everyone building it. That ratio is not sustainable for a development team with a full calendar of campaigns to build.
The industry's version of this story
Barbells for Boobs is not an unusual case. Every development director who has been in the sector for more than a few years has a version of this story. The platform that worked until the campaign got more complex. The migration that cost three months of productivity and still didn't solve the underlying problem. The new platform that solved the specific constraint that drove the migration and revealed a different set of constraints six months later.
What makes the churn invisible from the outside is that platforms don't retire logos. An organization that used a platform for two years, left, and went somewhere else remains on the client page. An organization that appears on three competitor platforms simultaneously creates the impression of three organizations' worth of social proof across the industry when it's actually one organization's migration history being counted multiple times.
This is not unique to any single platform. It's structural to how the category presents itself. The logo grid is always a frozen moment that doesn't account for movement. The honest version would distinguish between organizations currently active, organizations that left voluntarily and why, and organizations that left because they outgrew the platform or hit a constraint it couldn't resolve. That grid would look different from the one every platform currently shows. The departure rate, if it were published, would be the most useful single number in any platform evaluation.
What is your annual client retention rate, and what are the most common reasons organizations leave? A platform confident in its product will have an answer. A platform whose value proposition depends on the logo grid looking more impressive than the retention number justifies will redirect the conversation. How a platform responds to that question tells you more about what you're buying than any feature comparison does.
What I built instead
Manna is the direct result of a decade of hitting the same ceilings at different altitudes. The constraints I navigated at Barbells for Boobs across three platforms, and the patterns I watched other nonprofits run into while consulting for Funraise, became the feature list I refused to accept as permanent.
The Salesforce integration that worked on standard cases but broke on edge cases became the reason Manna's Salesforce sync is built with AES-256-GCM encrypted token storage, a queue-based idempotent sync engine, and field mapping that handles the actual complexity of how nonprofits structure their Salesforce objects. The campaign pages that couldn't carry the brand became the reason every Manna platform is designed specifically for the organization running it rather than configured from a component library. The shared databases that made data portability a platform-controlled question became the reason every Manna client gets their own independent database from day one. The migrations that cost months became the reason Manna built tooling specifically to make leaving a major platform as clean as possible, a subject covered separately in the notes on migration.
The platforms I worked with were not bad products. Classy in particular was and remains serious infrastructure. The people building it cared about getting it right, and the feedback I gave during those years was taken seriously in meaningful ways. Funraise built a team genuinely interested in what nonprofits needed and willing to bring practitioners into the conversation. The problem in both cases was not effort or intent. It was the fundamental architecture of building one platform for thousands of organizations. That model produces design decisions optimized for the median organization's needs. When your organization's needs are specific, complex, or growing faster than the template system can accommodate, you eventually find the wall regardless of how much input went into the product.
The platform churn cycle in nonprofit fundraising is expensive in every way that matters. It costs money in migration fees and integration work. It costs time that development and communications teams should be spending on campaigns. It costs institutional knowledge that lives in the workarounds your team built and evaporates when the system those workarounds were built for goes away. And it costs momentum, because every migration is a period where your fundraising program is in transition rather than in growth.
The way to break the cycle is not to find the platform with the longest feature list. It is to find a partner whose architecture doesn't have a ceiling at the altitude your program is heading toward. That requires understanding where the walls are before you commit, not after you've already built your campaigns around a platform that can't take you where you need to go.
I spent a decade finding walls. I built Manna so other organizations don't have to.
