A custom development contract: what the client should put in it to avoid depending on the vendor

Short answer: a good development contract passes one test. Could you carry on with the system if the vendor disappeared tomorrow? For that the contract needs rights to the code, the order and the moment the sources are handed over, servers, domains and accounts registered to your company, acceptance by stages with criteria somebody can check, and a statement of what you get if the contract ends early. The two things both sides always agree on are price and dates. These clauses are the ones that get left out.

We are developers, not lawyers, so what follows is what we see from inside projects. A finished contract is still worth showing to a lawyer.

Rights to the code

Our contracts are governed by Russian law, where article 1296 of the Civil Code gives the exclusive right to software created to order to the client, unless the contract says otherwise. So the thing to look for is exactly that “otherwise”: a clause that keeps the rights with the vendor and gives you a licence instead. Other jurisdictions default the other way and treat the developer as the author, which makes the clause more important, not less.

What the vendor brought with them is agreed separately: their own libraries, boilerplate, shared modules. They normally keep the rights to those. In that case the contract needs a perpetual licence to use and modify them as part of your system, otherwise there is code inside your product you cannot touch without asking.

Open-source libraries, which any modern system is built on, come under their own licences. Ask for a list with the licence of each one. It takes the vendor an hour and settles the question in advance of a due diligence or a sale of the business.

Handover of the source code

Write down what is handed over and when:

• the source code in a repository with its change history;
• instructions for building and deploying the system on a clean server;
• the database schema and a description of the integrations;
• handover in parts, after each paid stage.

The best arrangement is a repository created in your company’s account on day one, with the vendor working in it as an invited member. Then there is nothing left to hand over at the end.

Servers, domains and accounts

The server, the domain, the cloud account, the bot account in a messenger, the developer account in an app store, the payment provider keys: all registered to your company. The vendor gets access, the company stays the owner.

This is the most common way to end up dependent. Code can be rewritten. A domain or a bot registered to a developer’s personal account cannot be taken back without that developer. There is a similar risk with off-the-shelf products, covered in what happens to your data if the vendor shuts down.

Stages and acceptance

A development contract without stages turns into an argument at the end. It needs:

Stages with a result. Each stage ends with something you can check: a working module on a test server. “40% of the work completed” cannot be checked.

Acceptance criteria. What exactly gets checked, and on what data. Without them acceptance becomes an exchange of opinions. How to run it in practice is in how to accept work from a vendor stage by stage.

A review window. Contracts usually say that if the client sends no comments within a set number of days, the stage counts as accepted. That is a normal condition, but the window has to be realistic for your people. Five working days to review a module at the end of a quarter is not.

Scope changes

Scope moves in almost every project. The contract needs a procedure: who proposes a change, who estimates it in hours and money, who signs it off. Without one, changes get agreed in chat messages and an invoice nobody approved arrives at the end.

Warranty and support

A warranty covers the vendor’s own defects for a period after acceptance, most often three to six months. Support, meaning updates, small changes and response to incidents, is a separate agreement. More on that in what support after launch costs.

Personal data

If the vendor gets access to the personal data of your customers or staff, Russian data protection law treats it as processing on your instruction, and the terms belong in the contract: which data, for what purpose, under what protective measures. The simplest route is not to give developers access to the production database at all and to work on an anonymised copy. The same arrangement satisfies the equivalent rules in other jurisdictions.

Termination

Write down what you get if the contract ends halfway: the code as of the termination date, documentation for what was built, the access credentials. And which stages you pay for. The clause looks redundant at signing and becomes the main one once the relationship has gone wrong.

Common questions

Does a specification have to be attached to the contract? For the first stage a description of the result is enough. A detailed specification normally appears after the process has been studied and is attached to the development contract then.

What if the vendor refuses to hand over code before the end of the project? Ask why. The common answer, protection against non-payment, is solved by handover after each paid stage.

Can the vendor’s own template be used as the basis? Yes, that is normal practice. Check it for the clauses in this piece. Their absence from a template is not bad faith, but you will be the one adding them.

The rule

Read the contract as though the vendor will vanish a month after signing. Anything you could not get in that case has to be written in.