Before signing a development contract, check five things: what exactly is named as the deliverable (an itemized list, not "we'll build a website"); who gets the rights to the code and when — in writing; how stages are accepted and where the line is between a fix and a new task; what the post-launch warranty covers and how long it lasts; and whose accounts hold the domain, servers and repository. If the contractor answers even one of these evasively — that's a risk that will later cost more than all the savings.
Contents
Why "we'll take care of everything" is not a guarantee
In meetings every contractor promises the same: fast, high-quality, with heart. The differences begin in the documents: which of the promises is recorded in a way you can point to three months later, when all that remains is the correspondence and the contract.
A contract isn't a sign of distrust — it's a tool against misunderstanding.
A contract isn't a sign of distrust — it's a tool against misunderstanding, and it protects both sides: the client from "that wasn't included", the contractor from endless "just one more tweak". A telling marker: a solid contractor insists on a detailed contract themselves, because they work by it every day.
The subject of the contract: what exactly you will get
The most common source of conflict is a one-line subject: "website development". Each side reads its own meaning into that line, and the difference surfaces at acceptance.
The same goes for the handover format: code in which repository, documentation in what form, access to which systems. "Hand over the project" without specifics is the same one-line trap.
Code rights and access — in writing only
The block where mistakes are the most expensive. Check that the contract explicitly says:
- Rights to the code and materials pass to the client upon payment of each stage — not "after all work is complete" (otherwise a mid-project dispute leaves you with nothing).
- The repository is created in the client's organization, not at the contractor's "with access for you".
- The domain, hosting and key services are registered on the client's accounts — switching contractors must not require a "relocation".
- The list of access to be handed over is recorded: repository, servers, domain, databases, integration keys, analytics.
- A termination scenario is spelled out: what is handed over, within what time, what counts as paid.
Acceptance by stages, not "at the end"
A contract with a single final acceptance means you learn about problems when fixing them is most expensive. The normal scheme is stages with a working demo and an acceptance act for each.
What to record:
- The stage's duration and contents.
- The demo format (a live product, not screenshots).
- The time the client has to give feedback (yes, that's a client obligation — without it, "the contractor missed the deadline" often means "we didn't reply for a month").
- And crucially — the line between a fix and a new task.
The line's formula is simple:
A fix
- A mismatch with the recorded description
- Gets fixed within the stage
A new task
- A new wish
- Gets estimated separately
Both sides know the rules in advance, and acceptance stops being a negotiation.
The warranty period and what happens after launch
Launch is not the end of the relationship: something will surface on real users. Check three things:
The warranty period
- What to record
- For how long after launch errors are fixed for free, and what counts as an error: a mismatch with recorded behavior — yes; "let's move the button higher" — no
Support after the warranty
- What to record
- The format and terms — retainer, hourly, per request; reaction times for critical and non-critical issues
The difference between warranty and growth
- What to record
- Warranty fixes what was promised, growth adds new things
Red flags in a contract
- 100% prepayment before work starts — solid studios tie payment to stages.
- Code rights "after full payment of the whole project" — you've paid for intermediate stages but received no rights to them.
- Refusal to record the "not included" list — the boundaries will then be drawn mid-dispute.
- No termination-and-handover clause — you can't exit the relationship without losses.
- A template contract with no mention of your project's specifics — it wasn't written about you.
- "We guarantee search rankings / top spots in ChatGPT" inside a development contract — promising what the contractor doesn't control.
How it works at InterLAB
For transparency — our own setup, usable as a question list for any contractor:
Repository
- How we do it
- Created in the client's organization from the first commit
Work rhythm
- How we do it
- Two-week sprints with a live demo at the end of each
Payment
- How we do it
- Tied to stages (for the MVP sprint — 50% at the start, 50% at release)
"Not included in this stage" list
- How we do it
- Recorded at the brief
Handover
- How we do it
- After launch, documentation and all access are handed over
NDA
- How we do it
- On your template or ours
We're ready to walk through these points and show them in the contract before the start — check us against this very article.
