Own the Data Graph, Rent the Rest

I helped rebuild the platform for a membership organization with more than 8,000 members, and the whole project turned on one decision that most small organizations get exactly backwards. It's the build-versus-buy question, and the usual way of answering it — build the differentiated stuff, buy the commodity stuff — is right in spirit and useless in practice, because nobody can agree on which parts are which.

Here's the version that actually works, and it's the rule I now bring to every project like this: own the data graph, rent the rest.

The trap they were escaping

The organization came to us fed up with an all-in-one membership platform. It did everything — member records, email, events, payments, the website — and it did all of it in a way that held them hostage. Their data lived inside the vendor's system in the vendor's shape. Getting it out was hard on purpose. Every workflow was locked to how that vendor thought a membership org should run, which increasingly wasn't how they ran. And the price went up every year because the vendor knew exactly how painful leaving would be.

So they wanted out. Reasonable. But watch the trap they were walking straight into: they were shopping for another all-in-one platform. A different vendor, a nicer demo, a better price this year — and the identical lock-in waiting three years down the road. They were about to escape one vendor's grip by voluntarily putting their neck into another's. This is the single most common mistake I see organizations make when they leave a platform they hate. They replace it with the same kind of thing and act surprised when they end up in the same kind of place.

The problem was never the particular vendor. The problem was the architecture: they didn't own the thing that mattered most.

What actually is the business

So we asked a different question. Forget features. What, in this organization, is irreplaceable? What is the actual business, as opposed to the software wrapped around it?

The answer was the data. Specifically, a fairly small set of collections — members, their history, their engagement, their payments, the relationships between them. Ten to twelve core collections, roughly, that together are the organization in digital form. If you burned everything else down but kept those clean and complete, the organization survives and rebuilds. If you kept every fancy feature but lost or corrupted those, the organization is gone no matter how nice the email builder was.

That set of collections and the relationships between them — the data graph — is the thing worth owning. It's the moat. Not the software. The software is just this year's way of putting screens in front of the data. The data is the asset that has to outlive every tool you'll ever run it through.

So that's what we built and owned. The data graph, on boring, portable infrastructure — nothing exotic, nothing that ties you to one provider, the kind of standard, well-understood foundation you could move somewhere else in a weekend if you ever needed to. Deliberately unsexy, deliberately theirs.

Rent the commodity layers

Here's the part that surprises people: we didn't build much else. We rented almost everything around the data graph, and that was the right call.

Email delivery — sending thousands of reliable, non-spam-flagged emails — is a genuinely hard, fully commoditized problem that specialized providers have solved better than you ever will. Rent it. Payments — handling money, staying compliant, managing the machinery of transactions — is not a place a membership org should be writing code. Rent it. There's a whole layer of these: the commodity capabilities where dozens of vendors compete, where switching is easy because they all speak standard formats, and where building your own would be lighting money on fire to reinvent something worse.

The distinction that makes "build the differentiated stuff, buy the commodity stuff" finally usable is this: a thing is worth owning if losing it would end you and no vendor can hand you a replacement. A thing is worth renting if a dozen vendors offer it, they're interchangeable, and you could swap one for another next month without pain. Your member relationships and their history? Nobody can sell you those back. Email delivery? Ten companies will sell it to you by Friday.

Own the first kind. Rent the second. And critically — because this is where the lock-in sneaks back in — make sure the rented pieces plug into your data graph, not the other way around. The commodity layer serves your data. Your data does not live inside the commodity vendor. Keep that arrow pointed the right way and no single vendor can ever hold you hostage again, because your business isn't in any of their systems. It's in yours, and they're just services you point at it.

Why the moat is the model

When the rebuild was done, the organization owned the twelve collections that are the organization, sitting on infrastructure they controlled, with rented services doing the commodity work around them. If email delivery gets too expensive, they switch providers in an afternoon. If the payment vendor raises rates, they move. None of those switches touch the data, because the data was never trapped inside any of them.

That's a fundamentally different posture than "we bought a nicer all-in-one." They're not a tenant in someone else's building anymore. They own the land and rent the furniture, and furniture is easy to replace.

The instinct, especially for a smaller organization without a technical team, is to want one vendor to handle everything, because one vendor feels simpler. And it is simpler — right up until it isn't, which is the exact moment you want to leave and discover you can't. The slightly-more-deliberate path of owning your data graph and renting around it costs a little more thought upfront and buys you something the all-in-one can never sell you: the ability to change your mind. Your software will change many times over the life of your organization. Your data shouldn't have to move house every time it does.

Own the thing that is the business. Rent the things that merely serve it. That's the whole rule, and it's the difference between running your systems and being run by them.

You don't need a tech team to do this

The objection I hear from smaller organizations is that owning your own data graph sounds like something that requires engineers you don't have. It doesn't, and that's the part worth understanding, because the fear of it is exactly what drives people back into the arms of the all-in-one vendor.

Owning your data graph isn't about running servers or writing software. It's about a decision and a structure: your core member data lives in a standard, portable form that you control, and every tool you use reads from it and writes to it rather than swallowing it. Someone technical sets that up once — it's a bounded, one-time piece of work, not an ongoing engineering burden. After that, you're not maintaining a codebase. You're maintaining a clean set of records on a foundation that any tool can talk to, which is exactly what you were doing inside the old platform anyway, except now the records are yours and the tools are interchangeable.

The all-in-one feels easier because it hides this decision from you — it just makes the decision for you, in its own favor, and charges you for the privilege every year. Making the decision yourself, once, is the difference between a business that owns its future and one that rents it. You don't need a tech team for that. You need to insist on it before you sign.

If you're eyeing a platform switch — or you're locked into one and dreading the exit — the question to answer first is what you actually own. Here's how we work.