7 Warning Signs Your Development Company Has Too Much Control Over Your Technology

Software Vendor Lock-In Can Leave Your Business Without Real Control

Software vendor lock-in can creep up on a business without anyone deliberately making a bad decision. You hire a capable development company, they build the system, manage the hosting, look after the code and deal with problems. It feels convenient until you realise that changing supplier, reviewing the system or even accessing parts of your own technology requires their cooperation.

I have seen this type of dependency develop gradually. The issue is rarely that an external development company is involved. Good development partners can be incredibly valuable. The problem starts when your business cannot make meaningful technology decisions without them.

The question I encourage business owners to ask is simple: if your current development company disappeared tomorrow, could someone else keep your important systems running?

If the answer is no, you may have more risk than you realise.

Takeaways

What Is Software Vendor Lock-In?

Software vendor lock-in happens when moving away from a technology supplier becomes unusually difficult, expensive or risky.

It does not mean you should avoid long-term relationships with software companies. A trusted supplier that understands your business can be a major advantage.

The difference is choice.

You should continue working with a development company because they are doing a good job, not because your business has no practical way to leave.

Vendor dependency can come from several places:

• The development company controls your source code.
• They own or administer your cloud infrastructure.
• Important technical accounts are registered in their name.
• Nobody outside their team understands how your system works.
• Your business does not have current technical documentation.
• Contracts do not clearly deal with intellectual property and handover.
• The system relies on technology that only the supplier can realistically support.

That is why technology ownership is about much more than having paid the invoices.

Warning Sign 1: Your Development Company Controls the Source Code Repository

Your source code repository is one of the first things I would check.

For modern software, code is commonly stored in systems such as GitHub, GitLab or Bitbucket. The question is not simply whether the code exists. It is who controls the organisation and repository containing it.

If your development company owns the account and gives you limited access, your position is quite different from your business owning the repository and granting the development company access.

Ideally, your business should have appropriate administrative access to its core software assets.

That does not mean every executive needs to know how Git works. It means the organisation is not dependent on a supplier giving permission to access something critical to its operations.

Ask:

• Who owns the source code repository?
• Who has administrator access?
• Can your company remove or add developers?
• Is the full version history available?
• Is all production code actually stored there?
• Could another development team obtain the code without the existing supplier’s permission?

If the answers are unclear, investigate them.

There is also a separate legal question: who owns the intellectual property?

Those two things are related, but they are not the same. Having access to source code does not automatically establish ownership of the intellectual property.

For Australian businesses, this distinction matters. Australian Government guidance says contractors generally own IP they create unless the contract specifies that the hirer owns it.

That means “we paid for the development” should never be treated as sufficient evidence that the ownership position is clear.

Have your contract reviewed by an appropriately qualified lawyer if there is any doubt.

Warning Sign 2: Your Hosting and Cloud Accounts Belong to the Developer

Suppose your application runs in AWS, Microsoft Azure or another cloud platform.

Whose account is it?

I regularly distinguish between a supplier managing an environment and a supplier owning control of it. Those are very different arrangements.

A healthy setup might look like this:

Your business owns the cloud account.
Your development company has the access required to manage it.

That gives the supplier everything they need to do their work without transferring strategic control of the environment.

A higher-risk arrangement looks like this:

The application sits inside the supplier’s cloud account alongside systems belonging to their other customers.

That can create practical problems if you want to change providers.

You may need:

• infrastructure configuration
• database access
• backups
• DNS settings
• encryption keys
• deployment pipelines
• monitoring services
• log data
• storage accounts
• environment variables and configuration
• third-party service credentials

Moving an application is rarely as simple as downloading a folder marked “website”.

For important systems, your business should understand where everything runs and who controls it.

Security matters here too. Administrative access should be limited and properly managed. Frameworks such as the ASD Essential Eight and NIST Cybersecurity Framework provide useful principles around controlling and protecting technology environments.

Warning Sign 3: Important Technology Accounts Use the Developer’s Email Address

This one sounds trivial.

It isn’t.

Check who owns the accounts for:

• domain names
• DNS
• cloud hosting
• GitHub or GitLab
• app stores
• SSL certificates
• email services
• analytics
• monitoring
• payment services
• databases
• backup platforms
• API services
• third-party integrations

I would be uncomfortable seeing critical business accounts registered exclusively using someone@developmentcompany.com.

Your organisation should retain suitable administrative access using an account that it controls.

Why?

Because staff leave. Companies merge. Relationships change. Businesses close. Disputes happen.

You do not want to discover during one of those events that the password-reset email for a critical system goes to somebody you can no longer contact.

This is basic technology governance.

It is also an excellent example of my people before technology principle. The risk does not come from a sophisticated piece of software. It comes from a simple responsibility that nobody clearly assigned.

Warning Sign 4: Nobody Else Understands How Your Software Works

Ask your development company this:

If another competent development team had to take over next month, what would you give them?

A good supplier should be able to answer.

They might mention:

• architecture documentation
• setup instructions
• database documentation
• deployment procedures
• integration documentation
• API information
• infrastructure diagrams
• configuration
• source repositories
• support procedures
• known technical issues
• development standards

Not every SME needs hundreds of pages of technical documentation.

In fact, mountains of documentation can become another problem because nobody keeps it current.

The goal is different. Someone with the right skills should be able to understand what exists, how the important pieces fit together and how to safely work on it.

Poor documentation increases developer dependency.

This becomes particularly dangerous when the knowledge sits with one person inside the external supplier.

Technology due diligence work commonly examines source repositories, documentation, engineering capability, intellectual property and supplier dependency precisely because these factors affect whether a system can continue to operate and develop.

Warning Sign 5: You Cannot Easily Bring in an Independent Expert

This is one of my favourite tests.

Tell your development company you would like an independent technology consultant to review the system.

Then watch what happens.

A strong supplier should normally be comfortable with reasonable independent scrutiny.

They may quite rightly require:

• a confidentiality agreement
• controlled access
• security procedures
• limits on production access
• agreed timing
• protection of genuine supplier intellectual property

Those are reasonable precautions.

What concerns me is resistance to the principle of independent review.

Statements such as these deserve further questions:

• “Nobody else needs to see the code.”
• “It is too complicated for an outsider.”
• “That would create security problems.”
• “We can’t give anybody repository access.”
• “Everything you need to know is in our reports.”
• “There’s no reason to review it.”

An independent Technology Review is not an accusation against your software company.

Think of it more like getting a building inspection before buying a property.

You want somebody whose job is simply to tell you what they see.

That becomes particularly useful if:

• costs keep increasing
• delivery dates keep moving
• development has slowed
• you are considering a major investment
• you want to change supplier
• senior management cannot get clear answers
• the technology is becoming important to the value of the business

Independent review creates information. Better information creates better decisions.

Warning Sign 6: Your Contract Does Not Clearly Cover Ownership and Exit

Nobody gets excited about reading software contracts.

Unfortunately, they tend to become fascinating about five minutes after something goes wrong.

Look at what your agreement actually says about:

• source code
• intellectual property
• pre-existing supplier IP
• third-party software
• open-source software
• data ownership
• hosting
• documentation
• termination
• transition assistance
• credentials and account access
• source code handover
• confidentiality
• support after termination

For Australian businesses using contractors, IP deserves particular attention. Government guidance explicitly recommends that contracts identify who owns intellectual property, including software created during the engagement.

There is another wrinkle.

Modern applications rarely consist entirely of code written specifically for one client. They commonly use:

• open-source frameworks
• commercial libraries
• APIs
• SaaS platforms
• cloud services
• third-party components

You do not need to own everything your application uses.

That would often be impossible.

You do need to know the difference between your intellectual property and technology you have permission to use under somebody else’s licence.

A lawyer can assess the contractual position. A technology specialist can help identify the technical assets and dependencies that the contract needs to address.

The two disciplines work well together.

Warning Sign 7: Changing Development Company Feels Almost Impossible

Imagine telling your existing supplier:

“We are moving development to another company in 60 days.“

What happens next?

A controlled transition should be inconvenient, perhaps. Changing a team that knows your system always involves some effort.

It should not feel like a threat to the survival of the business.

If changing suppliers would mean rebuilding the entire system, losing access to important infrastructure or relying on the existing development company to cooperate indefinitely, you are dealing with serious dependency.

The warning signs can include:

Area	Healthy Position	Higher-Risk Position
Source code	Business has appropriate access and control	Supplier alone controls repository
Hosting	Business owns or can control environment	Everything sits inside supplier account
Documentation	Another qualified team can understand the system	Knowledge sits with current developers
Accounts	Business controls critical accounts	Accounts use supplier credentials
IP	Ownership and licences are documented	Nobody is sure who owns what
Deployment	Process is documented or repeatable	Only supplier knows how releases work
Exit	Practical transition process exists	No realistic handover plan

You do not need to fire your development company to test this.

Ask them to explain the exit process.

A professional supplier should understand why a responsible business wants continuity arrangements.

Ironically, suppliers that make it easy for customers to leave often build stronger relationships. The customer stays because of the service, not because somebody has locked the doors.

How Much Control Should Your Development Company Have?

This is where I want to avoid swinging too far in the opposite direction.

A business owner does not need personal control over every administrator password.

That would create its own security problems.

You also employ specialists for a reason. Micromanaging every technical decision defeats the point.

The better model is business ownership with delegated operational responsibility.

For example:

• Your company owns the AWS account.
• Your development partner administers it.
• Your company owns the GitHub organisation.
• Developers have the permissions necessary to work.
• Your company owns the domain.
• Your IT provider manages DNS.
• Your business owns the software IP where commercially appropriate.
• Developers can reuse their legitimate pre-existing tools and libraries according to the contract.

Governance should give people enough authority to do their jobs without giving one supplier permanent control over the business.

How to Check Whether You Have Software Vendor Lock-In

You can run a basic assessment without starting a major consulting exercise.

Start with these seven questions:

1. Where is our source code, and does the business control access to it?
2. Who legally owns the custom software and intellectual property?
3. Who owns our hosting, cloud and important technical accounts?
4. Do we have working administrative credentials?
5. Could another competent team understand and support the system?
6. What does our contract require if the relationship ends?
7. How difficult would changing supplier actually be?

Rate each answer:

Green: clearly understood and under appropriate business control.

Amber: partly understood, but access, documents or responsibilities need improvement.

Red: supplier-controlled, unclear or dependent on cooperation from one organisation or individual.

You now have a simple technology dependency map.

You may discover everything is fine.

That is a useful outcome too.

What Should You Do If Your Development Company Has Too Much Control?

Do not immediately turn it into a confrontation.

Most dependency is created gradually rather than maliciously.

A small business starts a project. The development company creates an AWS account because somebody has to. Then they create GitHub, register another service, set up monitoring and add integrations.

Two years later, the supplier appears to own everything.

Nobody deliberately designed it that way.

Start by documenting what exists.

1. Create a technology asset register

Record your critical:

• applications
• domains
• repositories
• cloud accounts
• databases
• SaaS services
• integrations
• administrator accounts
• vendors
• contracts

For each one, record who owns it and who controls access.

2. Confirm your legal position

Locate your development agreements and statements of work.

Have legal counsel review IP, licensing and termination clauses where necessary.

Technical and legal ownership need to line up.

3. Move strategic accounts under business control

Prioritise the accounts that could materially interrupt the business.

Do this carefully and collaboratively rather than changing credentials unexpectedly.

4. Improve documentation

Ask for the information another qualified developer would reasonably need to take over.

Focus on useful documentation rather than volume.

5. Test your backups

“Yes, we have backups” is not the same as demonstrating that you can recover from them.

Know where backups are stored, who controls them and how restoration works.

6. Reduce key-person dependency

Identify things only one person or supplier knows.

Document them or distribute that knowledge.

7. Get an independent review where the risk justifies it

For a business heavily dependent on custom technology, an independent Technology Review can examine ownership, access, architecture, security, documentation and supplier dependency.

If the technology is being assessed as part of an acquisition, investment or sale, a broader Technology Due Diligence review can examine whether the apparent technology assets and capabilities match reality.

The Difference Between a Valuable Partner and an Unhealthy Dependency

I am strongly in favour of long-term supplier relationships.

Businesses work better when good people understand each other and have time to build trust.

The warning is not “never depend on anybody“.

Businesses depend on employees, accountants, lawyers, suppliers, banks, cloud companies and advisers every day.

The goal is to understand where dependency becomes concentration risk.

A good development partner should add capability to your business.

They should not quietly become the only organisation capable of operating it.

That distinction matters even more as your business grows, raises capital, buys another company or prepares to sell. Technology due diligence commonly examines IP ownership, supplier concentration, key-person dependency, repositories and the ability of a business to maintain its technology after a transaction.

If your business cannot demonstrate control of its core technology, a potential investor or acquirer may see a risk that you have simply learned to live with.

Common Mistakes Businesses Make

Assuming paying for software means you automatically own everything

Payment, possession and IP ownership are different issues.

The agreement matters.

Waiting until the relationship breaks down

The worst time to discover your access arrangements is during a dispute.

Sort them out while everybody is still working well together.

Treating the supplier as the problem

Sometimes the supplier has repeatedly asked the client to take ownership of accounts and nobody responded.

Look at the situation objectively.

Demanding ownership of legitimate third-party technology

Your application may contain frameworks, libraries and supplier-owned components that your business should not expect to own outright.

You need appropriate rights to use them and clarity about dependencies.

Collecting passwords without fixing governance

A spreadsheet full of passwords is not technology governance.

You need appropriate ownership, access management, documentation and responsibility.

Frequently Asked Questions

What is software vendor lock-in?

Software vendor lock-in occurs when changing technology suppliers becomes excessively difficult, costly or risky because your organisation depends on the existing supplier’s systems, knowledge, access or proprietary technology.

Some dependency is normal. The problem is reaching a point where your business has no practical alternative.

Should my company own its source code repository?

For important custom software, I generally prefer the client organisation to have appropriate control and administrative access to the source repository, with developers receiving the permissions needed to work.

Source-code access and intellectual-property ownership are separate issues, so the contractual position should also be clear.

Do I automatically own software that I paid a developer to build?

Do not assume so.

Australian Government guidance says independent contractors generally own IP they create unless the contract provides otherwise. Your specific agreement and circumstances matter, so seek legal advice if ownership is uncertain.

How can I tell whether I am too dependent on my software company?

Ask what would happen if another development company had to take over within 60 days.

If you cannot provide source code, hosting access, documentation, credentials, architecture information and suitable contractual rights without the current supplier’s help, investigate further.

Should I get an independent technology review?

Consider one when technology is important to your business and you lack confidence about ownership, costs, security, architecture, delivery or supplier dependency.

An independent Technology Review can give you a clearer picture without requiring you to replace the existing supplier.

Final Thoughts

Your development company can be one of your most important business partners while your organisation still retains appropriate control of its technology. Good governance is not about mistrusting suppliers. It is about protecting people, customers and the business if circumstances change.

The aim is simple: keep the relationship because it works, while retaining the freedom to change it if necessary. That is how you reduce software vendor lock-in.