You own everything

“You own everything we build” is on our approach page. It is also on the homepages of approximately every consulting firm and SaaS vendor in the operations space. So the phrase is doing less work than it used to.

This is the post where we get specific about what it actually requires. Because the gap between the marketing copy and the technical reality is wide, and that gap is where lock-in lives.

The four things ownership actually means

You own a system when four conditions are true simultaneously. If any one of them is missing, you don’t own it. You’re renting it under a more flattering name.

1. Your data is in an industry-standard format and exportable on demand.

Not “available through the API.” Not “exportable via support ticket within 14 business days.” Available, today, in CSV or JSON or SQL, with the schema documented, by you, without asking anyone’s permission. If your vendor’s idea of an export is a button buried in admin settings that gives you a flat file of contact names with none of the relationships, custom fields, history, or attachments, you do not have your data. You have a souvenir.

2. Your code is documented, runnable, and yours.

If a consultant built you a custom system, you need the source code. In a repository you control. With a README that explains how to run it locally, how to deploy it, what the environment variables mean, and what the third-party dependencies are. “We host it for you” is fine. “You can never see what’s inside” is not.

The test: if your consultant got hit by a bus tomorrow, could a competent developer who has never seen the project clone the repo, follow the README, and have it running locally inside an hour? If no, you don’t have working software. You have a black box you are paying rent on.

3. You hold the credentials.

Every API key, every domain registration, every cloud account, every database connection string — in your password manager, on your accounts, billed to your card. If your vendor “manages” the AWS account that holds your customer data, they don’t manage it. They own it. You’re a tenant.

The legal layer matters here too. The cloud provider’s terms of service have you as a downstream party with no direct relationship. If the consultant disappears, you cannot recover the account. We’ve seen organizations lose three years of customer history this way.

4. Industry-standard tools throughout.

This is the one most people miss. Even if you have the code, the data, and the credentials, you don’t really own the system if it was built on tooling so esoteric that nobody else can maintain it. The promise of “no lock-in” requires that the next operator — whoever you hire after the current consultant leaves — can pick it up without learning a bespoke framework.

That means: a database engine the world uses (Postgres, MySQL, SQLite, depending on scale), languages people get hired in (TypeScript, Python, Go), deployment patterns that aren’t novel (Docker, standard cloud providers, well-known platforms), authentication that doesn’t reinvent the wheel. Boring choices. Boring choices are how you make systems portable.

The SaaS contrast

A typical SaaS contract is the inverse of all four. Your data is on their servers in their schema. You have no code, because you didn’t build anything — you configured. The credentials for the underlying infrastructure don’t exist for you to hold. The tooling is proprietary by definition.

This is fine when the SaaS is the right tool. We use SaaS. Some of our engagements end with the client running on a SaaS we configured, because that was the right answer for their scale and team and money. The key is that even there, the four-condition test still applies in spirit:

• Can you export your data in a usable format? (For most CRMs: technically yes, practically painful.)
• Is the configuration documented? (We document yours.)
• Are the credentials yours? (We make sure of it.)
• Is the platform itself industry-standard, or is it bespoke? (We avoid platforms you can’t leave.)

The contract is not “no SaaS ever.” The contract is “no exit penalty.” Sometimes a well-chosen SaaS is the lowest-exit-penalty option for your situation. Sometimes it’s not.

The checklist

Stealing from a draft we use with clients during scoping, here’s what to demand from any vendor — us, anyone — before you sign:

• Where does my data live? Show me. Whose name is on the account?
• Export my data right now, with full fidelity, in an open format. How long does that take? What’s missing?
• If you built me code, where is the repository? Whose GitHub organization? What’s in the README?
• List every credential, key, domain, and account this system depends on. Whose login owns each one?
• If you disappeared tomorrow, what’s the documented handoff path? Who could pick this up?
• What third-party services does the system depend on, and what happens to me if those services change their terms?

A vendor who can answer these crisply has thought about your exit. A vendor who hedges has not, and the answers will not get better after you sign.

Why we wrote this down

We made the four conditions part of our practice early on because the alternative — quietly accreting client dependencies you can monetize at renewal time — is a recognizable business model. It’s how a lot of consulting shops grow. We chose not to grow that way.

It also means clients leave. Some of our clients did leave, after a year or two, and took everything with them. That’s not a failure of the model. That is the model. The point of the work is that the system survives the engagement. If a client outgrows us, or finds a better fit, or just wants to bring it in-house, the handoff is a few hours and a fresh README.

If you’re evaluating a system you didn’t build and aren’t sure you own, run the four conditions. The answers will tell you a lot — about the system, about the vendor, about what your next move should be.

If this is your shape

You’ve inherited a tangle of vendor-managed pieces and you’re not sure what would happen if you wanted to leave any of them. You want one party who will lay the whole thing out, tell you straight what you own and what you don’t, and either fix it or help you plan around it.

That’s the work. Discovery call.