You Should Be Able to Fire Us Tomorrow
If this business decided to leave us tomorrow, could they walk away with everything they need? If the answer is no, we've built dependency, not value.
Here’s a test we apply to every client relationship we build: if this business decided to leave us tomorrow, could they walk away with everything they need to keep operating without us?
If the answer is no — if there’s a proprietary format, a locked repository, a domain we control, a processing relationship they can’t take with them — then we’ve built dependency, not value. And dependency is just a polite word for leverage we haven’t used yet.
The Ownership Illusion
Most technology providers will tell you that you own your data. It’s in the contract. It’s on the website. It’s technically true.
But ownership without portability is a lease dressed up in different language.
You own your data — but it exports in a proprietary format that only works with their system. You own your website — but it’s built on a framework that requires their ongoing involvement to maintain. You own your processing relationship — but your gateway integration is locked to their platform, and migrating means rebuilding from scratch.
The question isn’t whether you own it on paper. The question is whether you can do anything meaningful with that ownership if the relationship ends.
Most of the time, the honest answer is no. And the provider knows it. That’s the point.
How Portability Gets Quietly Killed
This rarely happens through an explicit decision to trap clients. It happens through a series of small, reasonable-sounding choices that each make the client slightly more dependent.
The developer uses a proprietary component library because it’s faster to ship. The payment integration gets hardwired to one processor because it simplifies the initial setup. The CMS stores content in a format that’s technically exportable but loses all its structure in translation. The domain gets registered under the agency’s account because it’s “easier to manage.”
Each decision makes sense in isolation. Together, they build a cage.
And here’s the part that doesn’t get discussed enough: this isn’t how companies intend to operate at the beginning. Most agencies, most SaaS platforms, most processors start with genuine intentions. But external pressure — the need to reduce churn, maintain recurring revenue, justify valuation multiples — creates a gravitational pull toward lock-in. The business model starts rewarding stickiness over satisfaction, and the architecture follows the incentives.
By the time anyone questions it, the switching costs are the strategy.
What We Build Differently
Our approach is straightforward, and it makes our business structurally harder to run. We do it anyway because the alternative is building something we wouldn’t want to buy.
Code and assets. Every website, application, or integration we build lives in a repository the client owns. Not “has access to” — owns. They can fork it, hand it to another developer, or modify it themselves. We build on open frameworks, not proprietary scaffolding. If we use a CMS, the client holds the account. If we register a domain, it goes under their registrar.
Processing relationships. We practice processor freedom. Clients work with the acquirer that best serves their business — Elavon, Moneris, whoever makes sense for their volume, industry, and card mix. We don’t steer merchants toward processors that pay us better residuals. Our advisory relationship is with the merchant, not the processor.
Data. Full export capability. Not “request your data and we’ll get back to you in 30 business days with a CSV that’s missing half the fields.” Complete, structured, documented data that a competent developer could integrate into another system without needing to reverse-engineer anything.
The Business Case for Letting Clients Leave
This sounds like it should be terrible for retention. It’s actually the opposite.
When clients know they can leave, staying becomes a genuine endorsement. Every month a merchant stays on our processing is a month we’ve earned through visible value, not invisible friction. Every development client who comes back for a second project chose us over the easier option of using someone else — because we made the first project portable enough that they could have.
The businesses that lock clients in get stable revenue until the client figures it out. The businesses that earn clients’ continued choice get something more durable — trust that compounds.
The Nugget: “Dependency is just a polite word for leverage we haven’t used yet.”
We’d rather have a client who stays for ten years because they want to than one who stays for two years because they have to.
If you’re not sure whether you actually own your technology stack, here are three questions to ask your current provider: Where is my source code? Who holds the domain registration? And if I left, what format would my data export in?
If the answers make you uncomfortable, that’s worth exploring.