The Vendor Dependency Trap — How Growing Companies Lose Control of Their Own Codebase

It rarely feels dangerous when it starts. You hire a software development agency to move fast on a product launch. Things ship. The team is happy. You're hitting milestones. Then your CTO decides to bring the project in-house — and discovers the code is undocumented, the deployment process lives in one person's head at the agency, and the infrastructure is set up under their AWS account. You are stuck. Not because you signed a bad contract. Because you didn't know what questions to ask before you signed a good one.

How It Happens

Vendor dependency isn't usually the result of malicious intent. Most development agencies aren't trying to lock you in. It's the natural result of optimizing for speed without optimizing for handoff.

When an agency's primary incentive is to ship features quickly, documentation becomes a casualty. Not because they're lazy — because documentation takes time and the client is asking for the feature, not the docs.

When a dev shop has proprietary tooling they've built over years, they reach for it naturally. It makes them faster. What they don't always flag is that this tooling creates a dependency.

When the same two engineers work on your project for eighteen months, they build deep context. Context that lives nowhere except in their heads.

None of these things feel like a trap while you're in a working relationship. They all become a trap the moment that relationship needs to end.

The Signs You're Already In It

Your internal team can't deploy without the agency. If pushing a release to production requires someone at the agency to run a script or push a configuration change, you have a deployment dependency. This is the most acute version.

The codebase has no README that actually works. If your lead engineer cloned the repository, followed the setup instructions, and couldn't get the development environment running within two hours, the documentation is not real.

There are services running that you don't fully understand. If there are services in your infrastructure that you can't identify the purpose of, or couldn't shut down and restart without help, that's a red flag.

The agency controls access to infrastructure. AWS, GCP, or Azure accounts set up in the agency's name — rather than your company's account with access granted to them — is a structural dependency that will cost real money and downtime to untangle.

Key knowledge sits with one or two people. If the only people who understand how your billing module works are two developers at the agency who've been on your account for two years, that knowledge doesn't belong to you.

What It Costs to Get Out

Getting out of a deep vendor dependency situation is not a one-afternoon project.

Knowledge extraction. Getting institutional knowledge out of an agency's team and into documentation takes weeks of structured sessions. You're paying for consulting that produces documentation that should have existed from day one.

Infrastructure migration. If the agency holds the keys to your infrastructure, migration means recreating environments, updating DNS, repointing services, and almost certainly causing downtime in the process.

Code archaeology. Undocumented code that has to be read, understood, and made maintainable by new engineers. Slow, unglamorous work that senior engineers dislike and junior engineers can't do alone.

The negotiation. Agencies that have leverage know it. If you're switching partners and they hold something you need, the negotiation for knowledge transfer and access handoff happens at a disadvantage.

In a serious dependency situation, the total exit cost — in engineering time, transition downtime, and product roadmap delays — often runs to six months of the agency's original contract value.

How to Prevent It Before You Sign

Vendor dependency is almost entirely preventable. The requirements that protect you are specific, contractual, and non-negotiable.

Require all infrastructure under your accounts. Your AWS, your GCP, your GitHub organization. The agency gets access. They don't own the account. This is a one-sentence requirement with enormous consequences if absent.

Require documentation as a deliverable, not an afterthought. Documentation should be in the definition of done for every sprint. Define what "documented" means: setup instructions that a new engineer can follow to run the environment locally within two hours. If they can't, the sprint isn't done.

Require no proprietary dependencies without disclosure. Any internal library, proprietary tooling, or custom package should be explicitly disclosed and approved. If an agency wants to use something they built, you need to either own a copy of it or require an alternative.

Require a knowledge transfer plan in the contract. Specify that the final phase of any engagement includes structured knowledge transfer: documented runbooks, architecture decision records, and a minimum number of pairing sessions with your internal team or incoming partner.

Test the documentation before you need it. At the end of each major milestone, have someone on your team — not the agency — follow the documentation and attempt to deploy. If they can't, the documentation isn't done.

What a Good Vendor Relationship Looks Like

None of this is adversarial. The best development partnerships are ones where the agency actively wants you to be in control of your own system.

Good agencies document not because they're contractually required to, but because they know that undocumented code is a problem they'll eventually deal with too — in the form of confused calls from you, expensive debugging sessions, and reputation risk.

> At Ontoborn, all infrastructure is set up under our clients' accounts — never ours. Documentation is a sprint deliverable, not a closing task. Every engagement includes architecture decision records and runbooks your internal team can follow. We structure every project so that on the last day of our engagement, you own everything and need nothing from us to keep it running.

Good agencies work inside your infrastructure, not their own, because they understand that the system belongs to you.

Good agencies onboard your internal team as they go, because a client who understands what's being built is a client who trusts the process.

The Questions to Ask Before You Sign

• •Can you show me the documentation from a recent project?
• •What does your definition of done include?
• •How do you handle infrastructure setup — under our accounts or yours?
• •What's your knowledge transfer process at the end of an engagement?
• •What happens if we want to bring this in-house in eighteen months?

The answers tell you more about a development agency than their portfolio.

The Opposite of Dependency: Ownership

The goal of a good development partnership is that at any point in the engagement — month three or month thirty — you could hand the codebase to a new team and they could run it.

Not seamlessly. Not without questions. But without months of archaeology and a negotiation with the outgoing agency.

This is what real software ownership looks like. And it's available to any company that requires it upfront.

At Ontoborn, we have been the long-term software partner for enterprises, universities, and growing businesses for over a decade. We do not just build and move on. We stay.

If you are looking for a partner — not just a vendor — we would like to talk.

Start a conversation →

Ontoborn Technologies is a custom software development and maintenance company trusted by enterprises, universities, and growing businesses for over a decade. We build software that lasts — and stay with you after launch.