Over the last decade working across multiple testing and quality engineering projects, I’ve seen one problem surface again and again — contractor lock-in.
It usually starts with good intentions: a specialist contractor is brought in to “accelerate delivery,” “improve automation,” or “set up a modern test framework.” But somewhere along the way, the organisation ends up dependent on that contractor — not just for expertise, but for the very ability to continue delivering.
How Lock-In Happens
Lock-in rarely happens overnight. It builds up slowly through several patterns:
- Proprietary Tooling – Contractors introduce their own commercial tools or frameworks that only they fully understand. These might come from their own company’s product line or an exclusive vendor relationship.
- Opaque Vendor Management – The contractor becomes the middle-man between your company and the commercial product vendor. They handle the licensing, integrations, and negotiations — which means the client loses visibility and control.
- Custom Frameworks with No Documentation – The contractor builds a bespoke automation framework that looks impressive but is overly complex, tightly coupled, and dependent on their expertise. When they leave, nobody else can maintain or extend it.
- Single-Vendor Dependence – With only one contractor team driving the testing or automation agenda, they gain outsized influence. Even if the engagement is “value-based,” timelines and outcomes can be stretched and justified by external factors “beyond control.”
In short — you end up paying twice: once to build the system, and again when you eventually have to pay them to help you move away from it.
The Impact on the Business
Contractor lock-in doesn’t just slow down delivery — it damages organisational resilience. Knowledge sits with external vendors, internal staff become passive consumers, and your ability to pivot to new tools or technologies becomes expensive and time-consuming.
Over time, this limits innovation, creates friction between teams, and erodes confidence in the QA function. What began as a partnership becomes a dependency.
How to Avoid It
From my experience, a few practical principles can help teams stay independent and resilient:
- Use Contractors to Supplement, Not Replace, Your Teams
Contractors should help upskill, mentor, and build alongside your internal team — not operate in isolation.
If you do need to bring in multiple contractors or even a full delivery team, engage at least two different companies. This diversity of input provides more balanced, unbiased opinions and prevents a single vendor from dominating the technical direction. - Favour Open Source Tooling — But Stay Cautious
Where possible, adopt open-source tools (like Playwright, Cypress, pytest, or Jenkins). They are community-supported, transparent, and easier to hand over.
However, be wary of “free” tooling that isn’t truly open source. Many vendors release free versions to gain market adoption, then commercialise once organisations have built dependencies on them. In those cases, the client becomes the guinea pig for the vendor’s early adoption phase — paying later through licensing or migration costs.
Always review the licensing terms, ownership model, and long-term roadmap before adopting any tool that seems “free.” - Keep Vendor Relationships in Your Hands
Always manage commercial tool contracts directly — don’t outsource this visibility. Ensure your company retains access, billing control, and support accounts. - Avoid Custom Frameworks That Reinvent the Wheel
Frameworks should extend well-known open-source solutions — not wrap them so deeply that the underlying tool is unrecognisable. - Build Cross-Functional Ownership
Encourage collaboration between BA, Product, Dev, and Test roles. Shared understanding reduces single points of failure and ensures that no single vendor “owns” the delivery pipeline. - Support Genuine Open Source Financially
Many companies rely on open source but invest nothing in it. Even modest funding helps improve tools we all use — and ensures the ecosystem stays strong, transparent, and vendor-neutral.
Final Thoughts
Contractor lock-in isn’t always intentional — but it’s always costly.
A healthy testing ecosystem is one that any capable engineer can understand, extend, and maintain without a single vendor holding the keys.
Be cautious not only with contractors but with tooling — even free tools can become traps once they pivot to a commercial model. Use vendors and contractors sparingly and strategically, as partners in capability-building, not as gatekeepers of delivery.
True quality engineering isn’t about dependence — it’s about empowerment, openness, and long-term sustainability.
