In this guide 6 sections
Settle five terms before the first sprint. Agree how change requests are priced and approved, what counts as accepted work, when intellectual property transfers and how long the warranty runs. Then tie each clause to the billing event it triggers, such as a deposit, a milestone or a retention release, so finance never invoices from memory.
Change control decides who pays for surprises
Every project grows. Say how in the contract. Be specific. A change request needs a written description, an effort estimate in days, a named approver on the client side and a revised delivery date.
Agree the rule for small changes too. Without a rule, a dozen thirty-minute tweaks eat a sprint, nobody can say who authorised them, and the reporting module slips by a fortnight. A common fix is a monthly allowance of small fixes, with anything beyond it going through a change request and its own estimate.
Link each approved change to a new line in the schedule of fees, so the invoice names the Stripe webhook handler or the extra role in the admin panel. The client sees what changed and why.
- Form for a change request and who may sign it
- Estimate method and rate card
- Effect on delivery dates
- Treatment of defects versus new requests
Acceptance needs criteria you can test
Acceptance is where most disputes begin. Write the criteria up front as runnable scenarios, such as a login with a wrong password, an export of one thousand rows or an invoice with three tax lines.
Keep the review period short. Five working days is typical. Silence counts as acceptance only if the contract says so, and it should also say whether an unreviewed sprint is held open, closed or billed as delivered. Name who signs. A project sponsor and a day-to-day product owner often disagree, so the contract must name one signer and one backup who can accept work.
Record acceptance in the tracker, not in an email thread, so finance can find the exact date and the named signer when the invoice is raised.
Intellectual property and what you reuse
State when ownership of the delivered code passes to the client, because many contracts pass it on final payment, which keeps the developer’s bargaining position until the money arrives. Others pass it milestone by milestone.
Carve out your own libraries, internal tools and frameworks, so the client receives a licence to use them inside the delivered product but never ownership of them. Open source components carry their own licences, such as MIT or GPL, so hand over the list with the code, because a buyer’s lawyers will ask for it.
Handover items belong here too. List repository access, Dockerfiles, build scripts, environment variables, API keys and the README, and record who received each item and on which date, so the handover can be proven.
- Transfer trigger: final payment or each milestone
- Licence for pre-existing tools and frameworks
- List of open source components and licences
- Repository, pipeline and credentials handed over
The warranty window and what it covers
A warranty window is a fixed period after acceptance in which you fix defects without charge, and a defect means behaviour that departs from the accepted criteria. A new feature is not a defect.
Say what falls outside it: changes to third-party APIs, hosting failures, edits by the client’s own staff and browsers released after go-live. Name the response time for each severity, since a priority one payment outage deserves a reply within hours while a misaligned label can wait for the next release.
Decide what happens when the window ends. Many teams forget this part. A support retainer or a time-and-materials rate keeps the work going without a new negotiation, and it gives the client one named contact for urgent faults.
Map every clause to a billing event
Build a grid of money clauses. Signature triggers the deposit, an accepted sprint triggers a milestone invoice, an approved change triggers an addendum, and the end of the warranty releases any retention.
Add the payment terms, the late fee and the right to pause work on overdue invoices, and settle them before sprint one, when both sides are still friendly. Include the currency, the tax treatment of cross-border invoices and who pays bank charges, since these small items often delay payments on international projects.
Before you send the draft, walk through the grid with your finance lead and confirm each event can be recorded in the tracker and invoiced from the accounting system.
Pre-sprint contract term sheet
A one-page grid has five rows, from change control to billing, and four columns for the agreed term, the owner, the evidence kept and the invoice triggered. A last row lists open points. Each carries a date to close.
Open a blank worksheet to printQuestions owners ask
Should a fixed-price contract allow change requests?
Yes. A fixed price covers a fixed scope. Anything outside the accepted scope should go through a written change request with its own estimate, approver and date, so the extra work is priced before it starts.
Who owns the code if the client stops paying?
That depends on the transfer clause. If ownership passes on final payment, the developer keeps it until then, and a lawyer in your jurisdiction should check the wording of that clause before you sign.
How long should a warranty window run?
The contract sets it, and the period varies with project size and risk, so write down the covered defects and start the clock at acceptance, not at delivery.
Can acceptance be automatic?
It can, if both write it in. A common form is acceptance after a set number of working days without written objection, provided the notice of delivery was sent to a named address. Keep a delivery log.