One dependency is built to keep you. The other is built to let you go.
In this guide
- Lock-In Is the Wrong Question. Commitment Is the Right One.
- A Vendor’s Business Model Is Your Retention
- Vendors Organize Themselves Around Keeping Customers
- Employee Incentives Point Outward
- Contracts Turn Incentives Into Obligations
- Vendors Can Disappoint, So Test Them Properly
- Leaving a Vendor Is Easier Than Leaving Yourself
- Questions That Reveal Real Commitment
- Frequently Asked Questions
Key Takeaways
- →Building does not remove dependence. It moves it from a company to a few individuals, which is a different relationship rather than no relationship.
- →A subscription vendor makes its money through renewals, so your success is its revenue for the whole life of the relationship.
- →Customer success, support and implementation teams have no counterpart in an internal build. Nobody’s job is making sure you get value from it.
- →Vendor risks can be assessed before committing and managed in the contract. A resignation cannot be forecast and cannot be contracted against.
- →Many organizations are more locked into their own code than they would ever be to a vendor, and there is nobody to negotiate the exit with.
Lock-In Is the Wrong Question. Commitment Is the Right One.
Lock-in asks the wrong question. Buying creates dependence on a vendor; building creates dependence on the people who built it and the choices they made. Neither offers independence. The useful comparison is which party gains more by keeping you successful, and what each has actually promised.
When organizations hesitate to buy software, the most common objection is lock-in. Once we commit to a vendor, the argument goes, we depend on its pricing, its priorities, and its continued existence. Building our own keeps us in control.
It is a fair concern, and it deserves a serious answer. But it rests on a hidden assumption: that building removes dependence. It does not. It moves dependence from a company to a few individuals. The better question is not whether you will depend on someone, but who is more committed to your success once you do.
Every option creates dependence. Buy a platform and you depend on a vendor. Build an app and you depend on the people who built it, the design choices they made, and their willingness to keep maintaining it. Neither option offers independence. Both offer a relationship.
Once that is clear, the useful comparison is between the two relationships. What does each party gain by keeping you successful? What does each lose if you fail? What obligations do they have, and what happens when circumstances change? Framed this way, the answer often looks very different from the one the lock-in argument suggests.
This reframing matters because the lock-in objection tends to shut down analysis rather than start it. It treats dependence on a vendor as a risk and dependence on internal staff as the natural state of things. Neither assumption holds up. Both forms of dependence carry risks, and both can be managed. The task is to compare them honestly.
A Vendor’s Business Model Is Your Retention
A software-as-a-service vendor does not make its money when a contract is signed. It makes its money over years, through renewals. A customer who leaves after the first term is often a loss once the costs of winning and onboarding them are counted. A customer who stays, expands, and recommends the vendor to others is where the business becomes valuable.
That creates a powerful incentive. A subscription vendor has every reason to make sure its customers succeed, because their success is its revenue. When a customer struggles, the vendor’s own interests push it to help. It is one of the few commercial relationships in which the supplier’s incentives and the customer’s goals point in the same direction for the whole life of the relationship.
The Two Dependencies, Compared
| Depending on a vendor | Depending on an internal team | |
|---|---|---|
| What they gain if you succeed | Revenue, at every renewal | Nothing directly tied to it |
| What they lose if you fail | The renewal, plus the cost of having won you | Nothing contractual |
| Who owns your adoption | Customer success, support and implementation teams | The same person who maintains it, extends it and answers every other request |
| Where long-term incentives point | Toward keeping you, for the life of the relationship | Toward their next role, inside or outside the company |
| What is written down | Service levels, data processing agreements, security commitments, notice and exit terms | Goodwill and a job description |
| Can you assess the risk in advance? | Yes: financial health, customer base, renewal and support record | Much harder. A resignation or reassignment cannot be forecast |
| Can you contract against it? | Largely yes | Almost impossible |
| How hard is it to leave? | A defined project: data export, open interfaces, clear end-of-contract terms | Bespoke data, logic few understand, possibly incomplete history, and nobody to hand over with |
Read the right-hand column on its own and it describes a relationship with no stated obligations, no assessable risk, and no agreed way out. That is the arrangement the lock-in objection treats as the safe default.
Vendors Organize Themselves Around Keeping Customers
This incentive is visible in how specialist vendors are structured. Customer success teams exist to make sure customers achieve what they bought the platform for. Support teams resolve problems. Implementation teams help with adoption. Product teams listen to customer feedback because it shapes what they build next.
None of these functions exist for an internal app. When an internal app has a problem, the person who fixes it is also the person who maintains it, extends it, and answers every other request. There is no team whose job is to make sure you are getting value from it.
Employee Incentives Point Outward
Engineers who maintain an internal app are, quite reasonably, thinking about their careers. Good engineers want to work on challenging problems, learn new skills, and advance. Maintaining an internal goal tracker is rarely the path to any of those things.
That does not make them less conscientious. It means their long-term incentives point toward their next role, inside or outside the company, rather than toward the app’s future. As an earlier article in this series explored, when they leave, they take much of the system’s knowledge with them, and there is no renewal at stake to encourage them to stay.
Ask a Vendor What It Has Promised in Writing
Contracts Turn Incentives Into Obligations
A vendor’s commitment is not only a matter of incentives. It is written down. Service-level agreements set expectations for availability and support. Data processing agreements define how personal data is handled. Security commitments specify controls. Contracts set out notice periods, renewal terms, and what happens to your data if the relationship ends.
An internal team operates on goodwill and job descriptions. There is no agreed level of availability, no defined response time, and no formal commitment about what happens if the team changes. Goodwill is valuable, but it is not the same as an obligation.
Profit.co publishes several of those commitments on its data security page before anyone signs. Customers own their data, and Profit.co does not provide it to third parties. Its SOC 2 controls are audited by an independent third party on an annual cycle, it holds ISO 27001 certification, and when a contract ends, business data is deleted and cleared from rolling backups.
Vendors Can Disappoint, So Test Them Properly
None of this means every vendor deserves trust. Vendors can raise prices, change direction, be acquired, or fail. These risks are real, and a sensible buyer examines them carefully: the vendor’s financial health, its customer base, its track record on renewals and support, and how it treats customers who need to leave.
The point is that these are risks you can assess before committing, and many can be managed in the contract. The equivalent risks of building, a key engineer resigning, a team being reassigned, or knowledge being lost, are much harder to assess in advance and almost impossible to contract against.
Leaving a Vendor Is Easier Than Leaving Yourself
The fear behind lock-in is being unable to leave. Good vendors make leaving possible, through data export, open interfaces, and clear terms for the end of a contract. Leaving is still work, but it is a defined project with a known starting point.
Leaving an internal build is often harder than it appears. Data sits in a bespoke structure that no other system expects. Logic is embedded in code that few people understand. History may be incomplete. And there is no counterpart to negotiate a handover with, because the people who built the system may already be gone. In practice, many organizations are more locked into their own code than they would ever be to a vendor.
That is before counting the strategy method baked into the data model, which is its own form of lock-in and the one hardest to undo.
Questions That Reveal Real Commitment
When comparing options, ask questions that expose commitment rather than features. What happens if our main contact leaves? What is the agreed response time when something breaks during a quarterly review? How do you help customers who are struggling with adoption? How do we get all our data out if we decide to leave?
Ask the same questions of an internal build. Who will maintain this in three years? What is their commitment to us? What happens if they leave? The answers usually make the choice clearer than any feature comparison.
Lock-in has long been the strongest argument for building. Seen clearly, it is an argument about commitment, and on commitment, a specialist vendor whose revenue depends on your renewal is usually the safer partner. That does not make building wrong in every case. It means the reasons for building have to be stronger than a fear of depending on someone.
So when is building the right answer? The next article makes that case honestly.
Choose the Dependency That Is Built to Keep You
Frequently Asked Questions
Rarely on its own. The objection assumes building removes dependence, and it does not: it moves dependence from a company to a few individuals. The better question is which party gains more by keeping you successful, and what each has actually committed to in writing.
Because a subscription vendor makes its money over years through renewals, not at signature. A customer who leaves after one term is often a loss once acquisition and onboarding costs are counted, so the supplier’s incentives and your goals point the same way throughout.
Obligations. Service levels set availability and support expectations, data processing agreements define how personal data is handled, security commitments specify controls, and exit terms say what happens to your data. An internal team has no agreed response time and no formal commitment if it changes.
Examine financial health, customer base, track record on renewals and support, and how the vendor treats customers who need to leave. These can all be checked before committing and many can be managed in the contract, which is not true of a key engineer resigning.
Usually the vendor. Leaving is work, but it is a defined project with data export, open interfaces and clear end-of-contract terms. Leaving an internal build means bespoke data, logic few understand, possibly incomplete history, and nobody to hand over with.
What happens if our main contact leaves? What is the agreed response time when something breaks during a quarterly review? How do you help customers struggling with adoption? How do we get all our data out? Then ask an internal build who maintains this in three years.
