Vendor lock-in is the quiet risk of every software outsourcing relationship. It doesn't announce itself at the start of the engagement. It reveals itself when you try to leave: the code is poorly documented, the architecture is tightly coupled to tools only the vendor controls, and there's no handover plan. Suddenly, switching costs feel prohibitive.
The good news: lock-in is preventable. It starts with the questions you ask before you sign.
Code Ownership
Ask: Who owns the intellectual property for code written during this engagement?
The answer should be unambiguous: you do. The vendor licenses their methodology, their team, their tools — but the output is yours. Get this in writing, explicitly. "Work-for-hire" clauses exist for this reason; make sure the contract uses that language or equivalent.
Red flag: Any hedging around IP ownership, or clauses that give the vendor a licence back to the code "for portfolio purposes" — that's a negotiation point, not standard practice.
Code Access
Ask: Will I have access to the source code repository throughout the engagement, or only at milestones?
You should have continuous read access to your own codebase. Not just at delivery. Every commit, every day. This isn't a trust issue — it's basic hygiene. If a vendor resists this, ask why.
Best practice: The repository should be under your GitHub/GitLab organisation, not the vendor's. The vendor's team gets invited as contributors. You own the organisation.
Documentation
Ask: What documentation will be delivered with the code, and what's your process for keeping it current?
Expect at minimum: a README that covers local setup, environment variables, and deployment steps; architecture decision records (ADRs) for non-obvious choices; and a data model overview for any non-trivial database. Ask to see documentation from a previous project — it tells you more than any promise.
Red flag: "We document at the end of the project." Documentation written retrospectively is almost always inadequate.
Handover Protocol
Ask: If we part ways — planned or unplanned — what does the handover process look like, and is it in the contract?
A good vendor has a standard offboarding checklist: credential transfer, knowledge transfer sessions, documentation review, and a defined transition period. This shouldn't be something you negotiate mid-exit — it should be written into the engagement terms from day one.
Technology Choices
Ask: Are any tools or services in this stack proprietary to your company, or difficult to replace?
Prefer open-source or widely adopted SaaS for every layer of the stack. If the vendor builds on a custom deployment tool, a proprietary monitoring solution, or a framework they maintain, you're dependent on them to stay solvent and interested. Open standards protect you.
The Exit Clause
Ask: What's the minimum notice period to end the engagement, and what happens to in-progress work?
Monthly retainers should have a 30-day notice period, maximum. Fixed-price projects should have a defined kill-switch clause: what you pay for work completed, and how deliverables are handed over if the engagement ends early.
What Transparency Looks Like
A vendor who has nothing to hide will answer all of these questions directly and offer to put the answers in the contract. A vendor who deflects, over-explains, or treats these as adversarial questions is showing you something important.
At SoftGodam, we give clients access to their repository from day one, maintain a standard documentation package on every project, and include a 30-day exit clause in all retainer agreements. Not because we expect clients to leave — because clients who feel free to leave choose to stay.