Letting someone outside your company change your code is a bigger decision than it looks on a proposal. The price and the timeline get the attention. The questions that decide whether you will be glad later are quieter: who owns what gets written, what the partner can reach, who says yes before a change goes live, and how you leave.
Ask them before the first change, while every answer is still cheap. Ask them of anyone you consider: an agency, a freelancer, a new vendor, or us.
Ownership: whose is the work?
The answer you want is short. The code written for you is yours, without conditions. Anything longer deserves a careful read.
- Who owns the code once it is written? Not “once the final invoice is paid”, and not “once the project ends”. Ownership that arrives late is leverage held over you in the meantime.
- Where does the work live while it is being done? If it sits with the partner until a handover, you own a promise rather than code. Work that lives in your own repository from the first day needs no transfer at all.
- What do you not get? Some partners keep parts back, such as a framework they license to you or a component they reuse elsewhere. That can be fine, but you should know exactly where the line runs before you depend on what sits on the other side of it.
- Could another team pick it up tomorrow? Ownership you cannot use is ownership in name only. Code that a competent stranger can read, build and change is code you actually hold.
Access: what can they reach?
Grant what the work needs and nothing more, and make sure you can see and withdraw it.
- What exactly will they need access to? A clear, short list is a good sign. “Admin on everything, to be safe” is not.
- Will they touch production data? Many changes can be made and tried without it. If a partner needs real customer data, ask why, and ask what happens to it afterwards.
- Who on their side can use the access? You granted it to a company. Find out how they keep it from spreading inside that company.
- Can you take it back in an afternoon? Access you cannot revoke quickly is access you do not control. Keep the keys in your own accounts and lend them out, rather than borrowing them back from someone else.
Security conversations often drift towards badges and certificates. Those have their place, but the four questions above are the ones you can check yourself, on your own systems, this week.
Approval: who says yes?
Nothing should reach your users unless someone on your side has agreed to it.
- Where will you see a change before it goes live? Not in a status report, but in the change itself, with enough explanation that you can follow what it does and why.
- Who on your side approves, and can they say no? A refusal that is expensive or awkward is not a real refusal. Make sure declining a change is an ordinary event rather than an escalation.
- How will you judge quality? Ask what comes with each change to show that it works: tests you can run, a page you can open, a before and an after. Quality you have to take on trust is only a hope.
- What happens when something slips through? Sooner or later it will, with any partner. Ask how quickly your users get a working product back, and who tells you.
This is also where control sits. A partner who decides what ships has taken over your product’s direction, however politely. A partner who brings each change to you for a decision has left the direction where it belongs.
Exit: how do you leave?
Ask about the end at the beginning, when nobody is offended by the question.
- What do you have on the last day? The answer should be everything you had the day before. If leaving requires an export, a migration or a negotiation, that is lock-in, however it is worded.
- What is the notice period, and what continues during it? Long tails are common in contracts and rare in proposals.
- Can your own team, or a different partner, carry on without them? The test is whether the work makes sense without the people who wrote it: a readable history, decisions written down, nothing that only runs on their machines.
- Can you start small? A partner who is confident in the work will let you try one piece before you commit to the rest. That is the cheapest exit there is: never going further in than you choose.
How to use the list
You do not need to send all sixteen questions in one email. Pick the two or three that worry you most and raise them in the first conversation.
Listen less to the words than to the shape of the answer. Short, plain answers usually mean the partner has been asked before and has nothing to hide. Long, conditional ones show you where to read the contract closely.
Then write the answers down where your team can find them. Settled in advance, these questions stop being a worry you carry into every meeting. That frees you to lift your eyes from the codebase to the product it serves.
Our own answers
Since we suggest putting these questions to everyone, here are ours. The work lands in your own code repository. The code we build for you is yours. We work within the access you grant, and nothing more. You decide what ships. Nothing reaches your users without your approval. Your code and your product stay yours to take anywhere.
It starts with a conversation, with no obligation. Bring the list.
