Get in touch
Get in touch
Choosing a partner

What to verify before you sign a development contract

The moment you have negotiating power with a supplier is before the contract is signed, and almost every unhappy engagement traces back to something that was assumed rather than written down at that moment. This is the list worth settling first: what you get at the end, what acceptance actually means, who owns what, and what happens when the estimate turns out to be wrong.

  • Name the handover artefacts as deliverables, not as a promise.
  • Make the acceptance test something a person on your side performs.
  • Settle what happens when the estimate is wrong before it is wrong.
  • Confirm IP ownership covers the specification and the checks, not just the code.

Every item here is cheap to agree before signing and expensive to argue about afterwards.

The handover, named as deliverables

Not "documentation will be provided". List them:

  • the specification the software was built from, current as at handover
  • the automated checks, runnable on your machines
  • a record of the decisions that would look wrong to a newcomer, with reasons
  • a runbook: deploy, roll back, logs, alerts, expected failures

If these are not deliverables in their own right, the engagement can be complete without them, and asking afterwards rarely works.

An acceptance test somebody performs

Acceptance should not be a date or an invoice. Make it an action: a named engineer on your side makes a real, user-visible change while the supplier watches without helping.

If they can, you own the software. If they cannot, you own a dependency, whatever the IP clause says.

What happens when the estimate is wrong

It will be wrong sometimes. Decide now who pays for it.

Fixed price puts it on the supplier, which is why fixed prices carry a risk premium and why suppliers argue firmly against scope changes. Time and materials puts it on you. Neither is wrong; not knowing which one you agreed to is.

Ask directly: "if this takes fifty percent longer than you estimated, what happens to my invoice?" An answer that is not a plain sentence is a warning.

IP that covers more than the code

Confirm ownership covers the specification, the checks, and the decision record, not only the source. On an AI-native build the specification and the suite are the parts that make the code maintainable, and a clause that transfers only "the software" can leave them behind.

Also confirm there is no dependency on a tool or platform you do not have a licence to.

Security, stated as a control

"We follow best practices" is not a clause. Ask for the specific automated checks that run on every change, and what happens to a change that fails one. Veracode's spring 2026 testing put AI-generated code at roughly 55 percent secure without explicit guidance, so this belongs in a contract rather than in a conversation.

The support window after handover

Agree a period where the supplier answers questions rather than making changes. The moment they start making the changes again, the transfer of understanding stops and you are back where you started.

What you keep if it ends early

If the engagement ends early, by either side: what do you keep? Work in progress, the specification, the checks so far. Agreeing this while everyone is optimistic is much easier than agreeing it while they are not.

Where we fit

Reveneau suits this when

  • You are about to sign with any development supplier
  • The last engagement ended in an argument about what was included

Common questions

What should be in a software development contract handover clause?
A handover clause in a software development contract should name four artefacts as deliverables rather than a promise: the current specification, the runnable automated checks, a record of the decisions that would look wrong to a newcomer, and a runbook covering deploys, rollbacks, logs and alerts. If these are not listed as deliverables in their own right, the engagement can be closed and invoiced without them, and asking for them afterwards rarely succeeds.
What is a good acceptance test?
A good acceptance test is an action, not a date on a calendar or an invoice being paid. A named engineer on your side makes a real, user-visible change to the software while the supplier watches without helping. If that change is released without problems, you own the software. If it does not, you own a dependency on the supplier, regardless of what the intellectual property clause in the contract says.
Fixed price or time and materials?
A software contract can be fixed price or time and materials, and both are legitimate structures that place the risk of a wrong estimate somewhere different. Fixed price puts that risk on the supplier, which is why fixed prices carry a premium and why suppliers argue firmly against scope changes. Time and materials puts the risk on you, the client. The real failure is signing without knowing which structure you actually agreed to.
Does IP ownership of the code cover everything I need?
Owning the code alone is often too narrow a guarantee. Confirm the intellectual property clause covers the specification, the automated checks, and the decision record, alongside the source files. On an AI-native build, the specification and the check suite are what make the code maintainable after handover, and a clause that transfers only "the software" can leave those parts behind with the original supplier, where your team cannot reach them.
How long should post-handover support last?
Support after a software handover should last long enough to cover at least one release cycle and one production incident, so the team can see the supplier handle a real problem before the relationship ends. Structure it so the supplier answers questions rather than making the changes themselves. Once they start making changes again, the transfer of understanding to your team stops and you are back where you started.
What should I ask about security in a development contract?
A development contract should require the specific automated checks that run on every code change, and state what happens to a change that fails one of them, since "we follow best practices" gives a new supplier or a court nothing to act on. This matters because Veracode's spring 2026 testing put AI-generated code at roughly 55 percent secure without explicit security guidance in the prompt, so security belongs in the contract itself rather than in a conversation.
What happens if the engagement ends early?
If the engagement ends early, by either side, the contract should say in advance what you keep. At minimum that should be the work in progress, the specification as it stands, and the automated checks written so far, handed over in a usable state rather than left on the supplier's systems. Settling this while both sides are still optimistic, before the contract is signed, is far easier than negotiating it after a disagreement has started.
Why does the moment before signing matter more than after?
The moment before signing a development contract is when you have the most negotiating power with a supplier, because every clause is still negotiable and nothing has been assumed yet. Almost every unhappy engagement traces back to something left unwritten at that point: what counts as done, who owns what, and what happens when the estimate turns out to be wrong. Settling these questions before signing is cheap; arguing about them afterwards is expensive.

Sources

Marked independent where the source has nothing to gain or lose from the answer. Anything from the other party is their own account and is labelled as such.

  1. Veracode, Spring 2026 GenAI Code Security update: more than 150 models across 80 tasks, 55 percent of generations secure, syntax correctness above 95 percent. Independent

Keep reading