Why these questions belong before the contract
During a sales process, attention goes to features, price and dates. Who will hold the code, the accounts and the knowledge when the work is done feels like a detail for later. It becomes the main subject on the day you want to change supplier, bring the work in house, sell the business or respond to a dispute. By then the contract is signed and the software is built, and whatever was left unsaid tends to be read in the vendor's favour.
Asking early costs nothing and tells you a great deal. A vendor who works transparently will answer every question below in a few minutes, because the answers are simply how they operate. Hesitation, vagueness or irritation is information too. This guide is not legal advice. Its purpose is to help you arrive at your lawyer with the right questions and the vendor's answers already in writing.
Questions about rights to the code
Ownership and licensing terms are defined in the project agreement, and the default position where an agreement is silent differs from country to country. Do not assume that paying for development settles the matter. Ask, and compare the answers with the draft contract.
| Question | A reassuring answer | A warning sign |
|---|---|---|
| What rights do we receive to code written specifically for this project? | A clear statement, matching a clause you can read | We can discuss that later, or a vague reference to standard terms |
| When do those rights pass? | At a defined point, such as on payment of each invoice | Only at final payment, with nothing if the project stops midway |
| Do you reuse your own existing components or frameworks? | Yes, listed, with a licence that lets us use and modify them for our product indefinitely | Yes, and they remain usable only while you are our client |
| May another company maintain and extend all of it? | Yes, including the reused parts | Only the custom parts |
| Do you retain the right to reuse what you build for us? | General know-how and generic components, not our business logic or data | Everything, without limit |
| Who holds rights to designs, content and documentation? | Covered alongside the code | Not mentioned |
Questions about third-party and open-source components
- 01
Which open-source libraries will be used, and under which licences?
Why it mattersMost are harmless for business use. A few carry conditions that could matter if you distribute the software. Ask for a list to be maintained.
- 02
Are any paid components, services or licences required?
Why it mattersFonts, maps, charts, editors, cloud services. Each is a running cost and a dependency.
- 03
In whose name are those licences and subscriptions?
Why it mattersThey should be held by your organization, so that they survive a change of vendor.
- 04
Are any components the vendor's own commercial products?
Why it mattersIf the system depends on a product the vendor sells, you are a customer of that product for as long as you use the system.
- 05
Will you tell us before adding a new dependency with cost or licence implications?
Why it mattersA simple undertaking that prevents surprises.
- 06
Is any code generated by AI tools, and what is your policy on reviewing it?
Why it mattersA fair question today. You want to hear that everything is reviewed, tested and checked for licence concerns by a person.
Questions about access and accounts
Rights on paper are of little use if you cannot reach the thing itself. Access should be yours from the first day, not handed over at the end.
- 01
Where will the code be kept, and who is the account holder?
A repository in an organization account that your company holds, with the vendor's developers invited. You can then see progress, and nothing has to be transferred later.
- 02
Who holds hosting, domains and app store accounts?
Your organization, paying the bills directly, with the vendor given the roles they need.
- 03
Who holds accounts for third-party services?
Payment, email, messaging, maps, analytics, monitoring. Yours, in each case.
- 04
Where are passwords, keys and certificates stored?
In a secrets store you control, never only on a developer's machine.
- 05
Can we see the work as it progresses?
Access to a test environment, the task board and regular demonstrations.
- 06
How is our data handled?
Where it is stored, who can reach it, whether real data is used in testing, how it is returned and deleted at the end.
Questions about documentation and the ability to run it
- What documentation do we receive? At minimum: how the system is structured, how to set up a development environment, how to build, test and deploy, how the environments are configured and how to recover from a failure.
- Could a competent developer who has never seen the project build and deploy it from the repository and the documents alone? This is the real test. Ask whether they would be willing to demonstrate it.
- Are there automated tests? They are what allow another team to change the system safely.
- Is deployment automated and scripted? Or does it depend on steps one person performs from memory?
- Who are the people on our project, and what happens if they leave? Knowledge held by one person is a risk whichever company employs them.
- Do you use subcontractors? If so, who, where, and under what terms do their contributions come to us?
- What warranty applies to defects after delivery? For how long, and what counts as a defect as opposed to a change?
A worked example
Two vendors answer the same questions
This example is invented to show how answers separate proposals that look alike. A recruitment agency is choosing between two companies to build a candidate portal. Prices are within a tenth of each other.
- RightsVendor A states what the agency receives for custom code as each invoice is paid, and lists two reusable modules licensed for indefinite use and modification. Vendor B says the code is released on final payment, and that its platform core is licensed while a support contract is in force.
- AccessVendor A proposes a repository and cloud account opened by the agency. Vendor B hosts everything on its own infrastructure and provides the code at the end on request.
- DocumentationVendor A shows an anonymized handover pack from a previous project. Vendor B says documentation is available as a paid extra.
- ExitVendor A offers a defined period of transition help at its normal rates. Vendor B's draft has no exit clause and a twelve-month minimum for support.
- OutcomeThe agency's lawyer reviews both drafts with these answers beside them. The agency chooses Vendor A, and asks for the answers to be reflected in the contract wording.
Vendor B's offer was not dishonest. It was a different commercial model, closer to renting a platform than commissioning software. The questions made the difference visible before signing, which is all they are for.
Questions about the end of the relationship
A healthy exit position
- Either side can end the engagement with reasonable notice
- Work completed and paid for is handed over whatever the reason for ending
- Transition help is available for a defined period at stated rates
- Access is removed by you, in an orderly way
- Your data is returned in a usable format and then deleted
A lock-in position
- Code released only at the very end, or only on request
- The system runs solely on the vendor's infrastructure with no export route
- A licence that lapses if support is cancelled
- Long minimum terms with automatic renewal
- No mention of what happens if the vendor is acquired or closes
Ask one further question plainly: if we decided to move to another company a year after launch, what would you hand over, how long would it take and what would it cost? A vendor who has thought about it will answer in specifics. Where a system is critical and the vendor small, ask also what protects you if the vendor ceases trading, since holding the repository and accounts yourself is usually the practical answer.
Turn the answers into contract terms
Send the questions in writing and ask for written replies. Compare the replies with the draft contract clause by clause. Where the contract is silent or says something different, ask for it to be changed to match what you were told. Then give your legal adviser the draft and the replies together. The cost of that review is small beside the cost of discovering the gaps later.
When the project ends, the same list becomes the basis for checking what you received. Our software project handover checklist covers that stage, and the guide on who should own app store accounts and source code goes deeper on mobile apps.
Pre-contract checklist
Ownership and handover questions checklist
0 of 11 checkedWhat to do next
Copy the questions from the tables above into a message and send it to every company on your shortlist, asking for replies in writing. The answers will differ more than the prices do, and they belong beside the proposals when you compare them.
We are glad to be asked every one of these, and our custom software development page describes how we work. Send us the list and we will answer it for your project.
Common questions
Do we automatically get the code if we paid for the software?
Not necessarily. What you receive depends on your contract and on the law that governs it, and the position where a contract says nothing varies between countries. Some agreements pass rights on payment, some grant a licence, and some keep parts with the vendor. Ask the question directly and have the answer written into the agreement.
Is it reasonable for a vendor to keep its own reusable components?
Yes. Most development companies bring libraries and tools they built earlier, and reusing them saves you money. What matters is the licence: you should be able to use, modify and have others maintain those components within your product indefinitely, without depending on a continuing contract. Ask for the components to be listed.
What is source code escrow, and do we need it?
Escrow places a copy of the source code with an independent party, to be released to you under defined conditions, such as the vendor ceasing to trade. It suits situations where the vendor keeps the code, as with licensed products. If the code sits in your own repository from the start, escrow adds little.
Should these questions be asked of freelancers too?
Especially so. With a single developer, the code, the accounts and the knowledge are often all in one person's hands, and that person may become unavailable without warning. The same arrangements apply at any scale: your repository, your accounts, written terms on rights and a short document on how to build and deploy.
What if the vendor's standard contract cannot be changed?
Then judge it as it stands, with your legal adviser, and decide whether the model suits you. Some vendors offer what is effectively a licensed platform with customization, which can be good value if you accept the dependency. What should be avoided is believing you are commissioning software you will control when the contract describes something else.
