Software development contract checklist: the clauses your vendor hopes you skip

We read software development contracts from the other side of the table. Every proposal we send comes back marked up, and every client contract we sign teaches us which clauses cause trouble half a year later. After enough of these cycles, a pattern shows up: the fights are never about the price on page one. They are about the six clauses most buyers skim.

Two notes before the list. First, we are not lawyers, and this is commercial guidance, not legal advice. For any build your business will depend on, pay a lawyer for an hour. This checklist exists so that hour is spent on wording, not on discovering that nobody agreed who owns the code. Second, everything below comes from the vendor side. We know which clauses agencies quietly prefer vague, because we have been that agency. Where our own preference runs against yours, we say so.

Who owns the code, and from which day

This is the clause that destroys the most value when it goes wrong, so it comes first.

The common wording assigns all IP "upon full and final payment." Read that literally and it means the agency owns everything until the last invoice clears. That sounds harmless on signing day. Then the project stalls in month three over a disputed change order, payments stop, and the client cannot legally hand the half-finished repository to anyone else. We inherited exactly this situation once: a founder arrived with a half-built product, a frozen codebase, and a previous vendor citing the contract correctly. Untangling it cost more in lawyer hours than the missing milestone was worth.

The fix is milestone-based transfer. IP in work that has been accepted and paid for moves to you when that milestone closes, not when the whole project ends. Each accepted milestone should leave you owning a working slice of the product. If the relationship ends early, you keep what you paid for and the vendor keeps what you did not.

One Germany-specific trap deserves attention. Under German copyright law, the copyright itself (Urheberrecht) cannot be transferred at all; only usage rights (Nutzungsrechte, Sections 31 and following of the UrhG) can be granted. A contract that promises a full "transfer of copyright" from a German developer promises something the statute does not allow. What you actually want spelled out is exclusive, irrevocable, transferable usage rights covering all known types of use, including the right to modify the code and to hand it to another vendor. The UrhG text is freely readable; the relevant part is short.

Settle reuse in the same clause. Agencies recycle generic utilities across clients, and that is fine as long as it is declared. The workable split, in our experience: your business logic and everything customer-facing is exclusively yours, while named generic libraries stay with the agency under a perpetual license to you. Both lists belong in an annex. "All code exclusively yours, no exceptions" sounds safer and usually dies in negotiation, because no agency signs away its toolbox. The annex is the compromise that holds.

What counts as done

Acceptance is where fixed-scope projects live or die, and it needs three parts: criteria, procedure, and a deadline.

Criteria first. "The app works as specified" has ended more friendships than any bug. Working criteria name the test: which user flows must run on which environment with which data, and what response times are acceptable. For a typical web app milestone we accept criteria like "a new user can register, complete checkout with a test card, and receive the confirmation email on the staging URL, with the ten named test cases in annex B passing." A buyer who cannot describe done in that much detail is not ready to sign a fixed price. That sentence will annoy some readers. It still holds.

Procedure second. Who tests, where, and for how long: the client tests on staging within ten working days of delivery, and reports defects as reproducible deviations from the agreed criteria. That last phrase matters. A defect is a deviation from the criteria, not anything the client dislikes. Everything else is a change request, priced under the next clause.

Deadline third. If the client does not respond within the window, the milestone counts as accepted. Lawyers call this deemed acceptance. Without it, one busy product owner can stall billing for a quarter. With it, silence means approval, which concentrates the mind wonderfully.

We once watched a project run four months on a thumbs-up given over a video call. No written acceptance, no test list. When the missing export button surfaced, the agency called it a new feature and the client called it a bug, and both were right under the contract they had signed. Which is to say: under a contract that defined nothing, both were wrong.

How changes get priced

Every project changes. The contract only decides whether changes arrive as a calm amendment or as an invoice-shaped surprise.

A working change-order clause has four steps and no shortcuts: the client requests the change in writing, the vendor replies within a set number of days with the cost and timeline impact, both sides sign, and only then does work start. Our internal rule is stricter than most contracts we sign: no ticket, no change, no invoice. Verbal "could you just" requests on status calls do not exist until someone writes them down. We enforce this on ourselves because the alternative is arguing about memory, and memory always bills in our favor. That is precisely why you should not rely on ours.

Draw the bug-versus-change line in this clause, not during the warranty fight later. Our working definition: anything that deviates from the accepted criteria is a defect and gets fixed free inside the warranty window; anything that adds behavior the criteria never described is a change and gets priced. Write that sentence into the contract. It looks pedantic on signing day and saves a five-figure argument in month five.

One honest admission: change orders are profitable for agencies, including us. Fixed-price vendors make their margin on the delta between the estimate and the change log. That does not make change orders a scam; it makes the pricing formula the thing to negotiate. Insist the clause states day rates for change work upfront. A vendor who refuses to name the rate for future changes plans to name it later, when you cannot walk away.

How either side can walk away

Nobody negotiates the exit when the relationship is good, which is exactly when exits are cheap to agree.

You want termination for convenience with a notice period, thirty days being the usual number. No-fault exit sounds like planning for failure. It is actually what lets both sides be honest mid-project: when leaving costs little, staying means something.

The clause that matters more than the notice period is the handover package. On exit, for any reason, the vendor delivers repository access with full history, credentials and infrastructure inventory, deployment documentation, and one recorded handover call with the team taking over. Most contracts we review say "the vendor will cooperate with the transition" and stop there. Cooperation is not a deliverable. A repository URL, a credentials vault, and a runbook are deliverables. Name them.

If you are scaling toward a long-term setup, this section deserves double the attention. Exit terms on a four-week build are a formality; exit terms on a team that holds two years of product knowledge are the whole game. Our dedicated delivery teams page describes how we structure the transfer side of that relationship, and the contract should mirror it.

Where the code lives if the vendor disappears

Source code escrow means a neutral third party holds a current copy of the code and releases it to you on defined trigger events: insolvency, support default, acquisition. Providers like NCC Group have run this business for decades. For a multi-year dependency on a single vendor, escrow is cheap insurance and we recommend it without reservation.

For a short build, escrow is usually the wrong purchase. Our position: if you hold full repository access from day one, with the code deploying from infrastructure you control, you already have what escrow would give you. Escrow protects against losing access; continuous access removes the risk instead of insuring it. The trade-off is real, though. Escrow also verifies that the deposited code actually builds, which your repo access does not guarantee. On anything above six months of vendor dependency, pay for both.

Whichever path you take, verify the trigger events in writing. An escrow agreement that releases the code only on formal insolvency does nothing when the vendor simply stops answering emails, which is the far more common failure. Support default with a cure period is the trigger that covers reality.

How long fixes stay free

Warranty windows in agency contracts run thirty to ninety days from acceptance. That range is customary, not mandatory, and two things in the clause matter more than the number: what it covers, and how fast the vendor must respond.

Coverage is defects as defined above, not new requirements, not third-party breakage, not "the new iOS version moved our buttons." Response times should be named per severity: critical defects acknowledged in one business day is a clause we sign gladly, because any team worth hiring meets it anyway. A vendor that haggles over acknowledging critical bugs within a day is telling you about its support bench. Listen.

German buyers get one statutory surprise here. Custom software built to order is generally treated as a Werkvertrag under the German Civil Code, which means a result is owed, and the default limitation period for defect claims runs two years unless the contract shortens it. Most agency contracts do shorten it, to the customary thirty to ninety days. That shortening is normal and usually acceptable. Sign it knowingly rather than discovering two years of assumed protection never existed. Hours billed under staff augmentation, by contrast, are usually a Dienstvertrag: effort is owed, no acceptance applies, and warranty works differently. Knowing which type your contract is decides which of the clauses above even bite.

The signature test

Read the draft once, looking for six answers. When does accepted work become mine. What test proves a milestone is done, and what happens if nobody runs it. What a change costs before the work starts. What I receive if we part ways. Where the code sits if the vendor goes quiet. How long defects get fixed free, and how fast.

A contract that answers all six in plain language is signable, whatever the price on page one. A contract that dodges two of them will cost you the uncovered amount later, with interest. If you are comparing proposals right now, our guide to choosing a software development agency shows how to vet the vendor behind the paperwork, custom vs off-the-shelf says whether the build is even the right line item, and our services page lists what we actually sign up for. Bring us a contract with all six answers filled in, through contact, and the first call is about your product instead of your paperwork. If you are pricing the build itself, our custom software development guide for Germany puts 2026 rates and inclusions in one place.