How EarthShare Grew Their Assets Under Management by Building Their Own Platform

When EarthShare's white-label SaaS started limiting what they could offer donors and partners, they made a decision that scares a lot of growing organisations: walk away from the off-the-shelf platform and build their own. Eighteen months later, the results speak for themselves.

$47 Million Increase in Assets Under Management after moving to their own custom platform

The problem with renting your platform

EarthShare is a US-based donor-advised fund (DAF) and giving platform that connects donors with environmental nonprofits. For years, they ran on a white-label SaaS product. It got them off the ground, and for a while, that was the right call.

But as EarthShare grew, the cracks started to show. The roadmap belonged to someone else. The workflows had to fit the vendor's idea of how a DAF should work, not EarthShare's. Donor and partner experiences couldn't be tailored. Every feature request was a negotiation with a third party. And the longer they stayed, the more locked-in they became.

There was another quiet cost too. Like most teams on white-label SaaS, EarthShare was paying for a full bundle of features every month and only using a fraction of them. The features they actually needed weren't in the product. The features in the product weren't quite what they needed. They were paying full price for partial fit.

This is the trap of white-label SaaS for any organisation that becomes successful enough to need something specific: the platform that helped you start becomes the ceiling on what you can become.

Why EarthShare chose to build

EarthShare came to Tinkso with a clear question: should we keep paying rent on a platform we don't control, or invest in owning what powers our entire business?

Build vs buy is one of the hardest decisions in any growing organisation. Building costs more up front. It takes longer. It carries delivery risk. But for EarthShare, three things tipped the balance:

• They had outgrown the vendor. Custom donor flows, partner views, and admin workflows simply couldn't be done within the white-label product.
• Their platform was their product. For a DAF, the donor experience is the business, and it can't be a generic experience the vendor also ships to everyone else.
• They wanted to own their roadmap. Every future improvement should be a decision they make, not a feature request they submit.

"The AUM growth we've seen is due largely to the stability and control we now have by truly owning our product roadmap."— Guy Derry, EarthShare

What we built

Tinkso designed and delivered a fully-owned, custom donor-advised fund platform for EarthShare. The scope covered:

• Custom workflows
• Donor and partner views
• A third-party disbursement engine integration
• An internal admin interface for approvals and editorial workflows
• A full data migration from the old system

A custom platform doesn't mean building everything custom. We integrate proven third-party services where they're a better answer than rebuilding, and we focus the custom work on the parts that actually differentiate EarthShare. That's how you keep cost and risk in check while still owning what matters.

The outcome

Since moving onto the custom platform, EarthShare has seen a $47 million increase in assets under management. The team attributes the growth to the stability and roadmap control that ownership has given them. They can now ship what donors and partners actually need, when they need it.

Beyond the headline number, the day-to-day reality has shifted too. The EarthShare team isn't waiting on a vendor for changes. They're not paying recurring SaaS fees for a product that wasn't quite right. They have one platform, built around their workflows, that grows with them.

Four lessons from the EarthShare migration

1. The migration is its own project

The hardest part of replacing a white-label SaaS isn't building the new platform. It's moving years of operational data cleanly into it. Donor records, fund history, donation data, partner relationships: all of it has to land in the new system without breaking the experience for the people relying on it. Plan the migration as a project of its own, not a footnote in the build.

2. Owning the roadmap is the durable win

Custom workflows and bespoke integrations are great. But the real, long-term advantage of owning your platform is being able to say yes to your own users without waiting for someone else's permission. Every feature decision becomes a business decision, not a vendor negotiation.

3. Build what differentiates, integrate the rest

Going custom doesn't mean rebuilding payments, identity, document signing, or every other category where mature third-party services already exist. The strongest custom platforms integrate best-in-class services for commodity functions and focus engineering effort on what actually makes the product distinctive.

4. Consider adoption from day one

New software means new processes, and changing processes (even tedious ones) is genuinely hard for most teams. People build muscle memory around the workarounds, the Excel sheets, the manual steps. A new platform asks them to let those go and trust something different. You need a partner who understands that psychology and helps you manage the change internally, with your own team, and externally, with your customers. The best technical build in the world fails if the people using it never come along for the ride.

Is your SaaS platform becoming your ceiling?

If your team finds itself working around your platform more than working with it, submitting feature requests that go nowhere, building manual processes to fill product gaps, or worrying about vendor lock-in, it may be time to ask whether the platform that helped you start is the right one for where you're going next.

If that question is on your mind, we'd be happy to talk. Tinkso designs and builds custom platforms for organisations who've outgrown off-the-shelf software.

FREQUENTLY ASKED QUESTIONS

Build vs Buy: questions teams ask before making the move

When should you consider moving from SaaS to a custom-built platform?

The clearest signal is that your team is doing more and more work around the software, instead of with it. The everyday symptoms are easy to recognise: lots of manual workarounds, a growing pile of Excel sheets propping up processes the software can't handle, multiple tools stitched together to cover gaps, slow or unresponsive vendor support, an outdated user experience, features that have been on the roadmap for years and never arrive, and a creeping suspicion that you're paying for a bundle of features you're not actually using. Add vendor lock-in to that picture and the maths starts to shift. If your platform is the business (meaning the experience your customers receive is the product), owning it is worth seriously considering.

How much does it cost to build a custom platform compared to staying on SaaS?

Building costs more up front. Ongoing, the maths often reverses. You stop paying recurring per-user or revenue-share fees, you stop paying for features you don't use, and you stop losing revenue to the things your SaaS can't do. Over time, a custom platform tends to pay for itself. In EarthShare's case the ROI was almost immediate, thanks to the AUM growth that followed the move. There's also a balance-sheet angle that's often overlooked: software you own is an asset, not just an expense line. That matters for valuation, and it's particularly attractive to acquirers who want to see real intellectual property behind the business rather than a stack of SaaS subscriptions that disappear the moment payments stop.

How long does it take to migrate from a SaaS product to a custom platform?

It depends on the complexity of the system, the amount of historical data, and (honestly) how quickly the client can make decisions, give feedback, and provide access to the things we need. Some projects move from kick-off to live in a few weeks. Others run over several months. The build itself is usually the predictable part. The data migration and cutover often deserve to be planned as a project of their own. We'd rather give you a realistic timeline based on your situation than a generic number that won't apply to it.

What should you look for in a custom software vendor?

Technical expertise is the baseline. Assume that everyone you're shortlisting can write good code, then look beyond it. The qualities that actually decide whether the project succeeds are: a vendor who takes the time to understand your business properly (the relationship is going to get intimate, they'll know your workflows better than some of your own team), strong service and communication so you're never wondering what's happening, good chemistry with the people who will actually be doing the work, an understanding of human behaviour and adoption (because a brilliant build that nobody uses is a failure), and creative thinking that brings you options you hadn't considered rather than just executing your brief. The right vendor pushes back when something doesn't make sense and suggests better alternatives when they see them.

Can I build my own software using no-code, low-code, or AI-assisted coding tools?

Yes, you can, and for the right problem these tools are genuinely powerful. We use them ourselves where they fit. Where things tend to get complex quickly is in the parts you can't see: how the data is structured, how the system will scale as your usage grows, how secure it is against the kinds of attacks real platforms face, and how easily it can be maintained and changed a year from now. Those decisions are easy to get wrong and expensive to fix later. The other question worth asking is whether your time is best spent on this at all. If you're a founder, a director, or a domain expert, your hours are usually more valuable doing the thing only you can do, rather than wrestling with a build that a specialist could deliver faster and more reliably. AI and no-code lower the floor, but they don't remove the need for the thinking.

What's the biggest risk in moving off a white-label SaaS platform?

The data migration. Years of operational data (donor records, transaction history, partner relationships) has to land in the new system cleanly, or the experience for existing users breaks on day one. The build itself is usually the predictable part. The migration is where projects most often run into trouble, which is why we treat it as a project in its own right.

What does Tinkso do?

Tinkso is a custom software company that designs and builds platforms for organisations who've outgrown off-the-shelf software. We work end-to-end, from discovery and design through to engineering, migration, and ongoing partnership, and we're typically brought in when an organisation needs a platform built around their workflows rather than the other way around.

Want the full EarthShare case study?

The full case study lives on the Tinkso website. You can read it there, or email us and we'll send you the PDF directly. If you're weighing up a similar decision in your own organisation, it's a useful read whether you end up leaning build or buy.

This post was written by an actual human, with AI as a drafting partner. The human did the thinking, gave a lot of feedback, and made the final call on every paragraph. The AI just typed faster.