What you are actually buying: the spec as an attachment
The main source of conflict is not money, it is two different definitions of the word "website". To you it is a working tool with forms, integrations and pages filled with content. To the developer it is whatever the contract lists. If the contract says "development of a corporate website", you both lose the argument.
The specification should be a separate attachment that the main contract refers to. Not "in accordance with the Client's wishes", but "in accordance with Attachment 1". The attachment gets signed together with the contract.
Check that the spec lists pages with counts, not "a set of standard pages". Otherwise eight catalogue pages easily turn into two plus an extra invoice.
- A list of pages and templates - itemised, with counts
- What happens to content: who writes the copy, who sources the photos, who fills in the product cards
- Integrations by name: CRM, payment provider, delivery service, email, analytics
- Responsive behaviour: which screen widths and which browsers the result is checked against
- What is NOT included - this clause is more useful than half the others
Acceptance: how you know the work is delivered
Weak wording: "The work is deemed accepted in the absence of objections from the Client." That means silence equals approval, and silence has no deadline. Strong wording sets two things: a review window and the criterion you review against.
Ask to add: the client has N business days to review, comments are submitted as a single written list, and the developer fixes anything that contradicts the spec at no charge. The distinction matters: not matching the spec gets fixed on the developer's time, changing the spec costs extra. Without that line, every fix becomes a negotiation.
Spell out where acceptance happens. A staging domain you can open yourself, not "we'll show you on a call". You need to be able to pull the site up on your phone and show it to colleagues.
Ownership of the result and access
By default the exclusive rights to the code and design stay with the author - the developer. If the contract says nothing about it, you got a website but not the rights to it. The practical consequence: another studio cannot legally work on your site, and you formally cannot use the design in advertising.
You need a clause transferring exclusive rights to the work product to the client upon full payment. Cover third-party libraries and templates separately: if the project uses a paid theme or a premium plugin, the licence should be in your name, not the developer's.
Access is the other half of this clause. Register the domain yourself, not "through the studio". Hosting and the control panel go in your account too, with separate credentials issued to the developer. If the site is hosted on the developer's infrastructure, the contract needs a clause requiring a full export of files and the database on your request.
- Domain, hosting, analytics, email - accounts in your name and on your email
- Source code delivered to a repository you have access to
- Third-party component licences issued to the client
- Rights transfer after full payment - that is a fair condition, agree to it
Money: milestones instead of two payments
The "50% up front, 50% on delivery" model works badly on projects longer than a month. The client has a deposit at risk, the developer has half the budget at risk, and both sides are on edge.
Ask for a breakdown into milestones, each paid on delivery: design, front-end build and functionality, integrations and launch. Each milestone has its own result you can look at. It keeps both sides disciplined and it lowers the cost of being wrong: if something goes sideways, you part ways at a milestone rather than at the end.
Check separately how out-of-scope work is billed. Normal practice is an hourly rate fixed in the contract plus written sign-off on the volume before work starts. A rate that gets discussed after the fact always turns out higher than you expected.
Revisions, warranty and termination
"Unlimited revisions" is a red flag, not a gift. Nobody honours that condition, and in practice you run into an informal "we've already redone a lot". It is more honest to agree on a finite number of rounds per stage: two rounds on design, say, and anything beyond that at the hourly rate.
The warranty period is about defects, not about new work. The wording should separate the two: the developer fixes, free of charge, anything where the site does not behave as described in the spec. New requests are not covered by the warranty, and that is fair.
The termination clause gets read last and matters most. It should say what happens to the money already paid and to the work already done if you decide to stop. A reasonable arrangement: the client pays for the volume actually completed and accepted, and the developer hands over everything produced up to that point, including source files and design files.
And check the support section. What is included, at what price, how fast the developer responds when the site goes down. If support is not in the contract, you are on your own after launch - sometimes that is fine, but it is better to know in advance.
When a simpler contract is enough
Not every job needs a multi-page document. A one-week landing page, a markup fix, a form setup - a heavy contract with milestones and formal acceptance creates more friction than protection here. An invoice or a short agreement is enough, stating what gets done, what it costs and that the access is yours.
A full contract earns its keep when the project runs longer than a month, when there are integrations with outside systems, when the site takes payments or collects personal data. Simple rule of thumb: if the project falling apart would visibly hurt the business, you want the detailed version.
One more thing: a contract will not save you from a bad developer. It lowers the cost of mistakes and removes ambiguity, but few people will go to court over a modest sum. So alongside the legal review, watch how the developer answers questions before signing. Someone who calmly explains why their contract is worded the way it is usually works the same way.
What to do before you sign
A practical minimum that takes one evening. Read the contract from the back - the sections on termination, rights and liability are usually the most honest. Write down every place the words "to be agreed by the parties" and "within a reasonable time" appear: those are deferred arguments, and they are worth decoding now.
Ask for the estimate as a list of blocks and tasks, not a single line. One line with a total is not an estimate, it is a number, and it cannot be compared against another studio's proposal.
Ask the developer three questions directly: whose name the domain is registered in, where the code will live, and what happens if we decide to part ways halfway. The answers will tell you more about the work ahead than the portfolio does.
- Domain and hosting in your accounts, verified before the start
- Spec signed as an attachment, with a "not included" section
- Review window and number of revision rounds - as actual numbers
- Rate for out-of-scope work - in the contract
- Termination terms: what happens to the money, what happens to the work
A contract protects you through precise wording rather than the size of the penalty clause: a signed spec, acceptance deadlines, transfer of rights, access in your name, and clear termination terms. At EFIMOV DEV we publish starting price ranges for each service on our site - from landing pages and corporate sites to online stores, Telegram bots and support; the exact estimate is assembled after the brief as an itemised list of tasks, so it can be attached to the contract and checked.
Frequently asked
Do you really need a contract when working with a sole trader or a freelancer?
Yes, and especially in that case. A contract with an individual works the same way as with a company, and it is also what lets you account for the expense on your side. If a developer refuses to work under a contract, you lose both legal protection and the ability to write off the cost. The minimum viable version is a services or works agreement plus the spec as an attachment.
Who owns the site's code by default if the contract says nothing about it?
The author, meaning the developer. Paying for the work does not by itself transfer exclusive rights. That is why you need a separate clause moving the rights to the result over to the client upon full payment - otherwise you own the site in practice but not in law.
What deposit amount is reasonable?
On short jobs, 50% up front is standard practice. On projects running a month or longer, it is better to split the budget across milestones: a payment after design is delivered, after functionality, after launch. Paying in full up front on a large project is a risk with nothing to offset it.
How do you write the price into the contract when the scope is still unclear?
Fix two numbers: the cost of the first stage, where you define the scope (brief, prototype, spec), and an hourly rate for everything after that. Once the first stage is done, you sign an addendum with the exact figure. That way you are not committing to a wide "from X to Y" range for the whole project and not overpaying for uncertainty.