Website Development Agreement. 12 Clauses That Determine Whether You Pay for a Finished Product or for Chaos.

Your software house has just emailed you to say that a stage of the website is ready. You were at a trade fair and did not reply for a week. You come back – the website looks different from the mock-up. The problem: the stage has been unconditionally accepted. Revisions? They are now additional work billed at zł 250 per hour.

This is how a deemed acceptance clause works – and it appears in most website development agreements.

We analysed a real website development agreement. The result: 12 clauses that determine whether you pay for a finished product or for chaos. In this article, I break each of them down – using business language, not legal jargon. You will learn where clients most often lose money, control over the project and the rights to their own website. At the end, you will find a checklist that you can take to a meeting with the contractor.

Before you read on – a few terms you need to know

Polish law does not provide for a separate type of website development agreement. Web development contracts are classified either as a contract for specific work (Article 627 of the Civil Code) – an obligation to achieve a specific result – or as a service agreement (Article 750 of the Civil Code) – an obligation to exercise due care. This distinction affects the acceptance procedure, liability for defects and when payment becomes due.

12 website agreement clauses that determine whether the project succeeds

1. Scope of work and description of the subject matter of the agreement

This is the foundation of the entire agreement. If the scope is described in general terms (“a modern website with a contact form”), every discrepancy between your vision and the contractor’s work will become a dispute over interpretation.

What the description of the subject matter of the agreement should include:

1. A list of features divided into phases (e.g. Phase 1: graphic design, Phase 2: front-end coding, Phase 3: integrations)
2. Non-functional requirements – performance, responsiveness, supported browsers
3. A list of technologies and tools (WordPress, ACF PRO, React, etc.)
4. Clear exclusions – what is NOT included in the scope (e.g. WCAG 2.1, SEO, copywriting)

The lack of a precise description is an invitation to scope creep – the uncontrolled expansion of the project scope, which is discussed in more detail in section 9.

2. Schedule and division into stages

A project divided into phases with specific dates gives you control over its progress. Each stage should end with a measurable deliverable – e.g. a completed graphic design in Figma or a working front end in the development environment.

Pay attention to two things:

1. Prerequisites on your side – if the agreement requires you to provide the graphic design in Figma (desktop + mobile) 2 business days before the start date and you fail to do so, the start date will be postponed through no fault of the contractor
2. Consequences of a pause in the work – a pause caused by you that lasts more than 30 days may trigger an additional “project resumption” fee charged at the rates for additional work

3. Fees and payment terms

A typical phased model links payments to project milestones. An example breakdown: 30% at the start, 30% after acceptance of the graphic design, and 40% after final acceptance.

For a project worth zł 27,400 net, an additional work rate of zł 500/h means that 55 hours of out-of-scope work will double the project budget.

4. Deemed acceptance of stages

This is one of the riskiest clauses for the client. The mechanism works as follows: the contractor notifies you that a stage is ready, and you have, for example, 5 business days to submit comments. No response = unconditional acceptance.

Polish case law confirms the enforceability of such clauses. The Warsaw Regional Court (XXIII Ga 978/20) held that a clause stating “5 business days to submit objections; no objections = the work is accepted” is valid and effective in business-to-business relationships. The court linked the client’s silence to its actual use of the work.

How to protect yourself:

1. Decide internally who in the company is responsible for reviewing each stage
2. Set calendar reminders for 2 days before the acceptance deadline
3. Negotiate a deadline appropriate to the complexity of the project – 5 business days to review a website with 15 subpages and integrations is not enough
4. Make sure that the clause does not deprive you of the right to report defects discovered after acceptance

The final acceptance deadline may be longer – e.g. 10 business days. But the mechanism works in the same way: no response = unconditional acceptance of the entire project.

Contact us

5. Copyright – when the website truly becomes yours

Under the provisions of the Copyright and Related Rights Act, an agreement requiring the assignment of economic copyright transfers those rights upon acceptance of the work – unless the parties have agreed otherwise. And this “otherwise” is standard in web development agreements.

A typical clause states: copyright is not transferred to the client until the final instalment has been credited. Until then, you only have a limited licence – for example, to conduct testing in the development environment.

What this means in the event of a dispute:

1. You have paid Instalments I and II (a total of approx. zł 16,000 net)
2. The website is running in the development environment
3. There is a dispute over the scope of the final phase – you withhold Instalment III
4. You do not own the copyright to the code – you only have a testing licence
5. The contractor may prevent the production launch

Two things to negotiate:

1. The assignment of copyright requires written form to be valid – oral agreements to assign copyright are invalid
2. Consider an emergency licence (escrow) in the event of a dispute – the code is deposited with an independent third party, with the release conditions specified in the agreement

Good practice when negotiating IT agreements: follow the principle of “only as many rights as are genuinely needed”. You do not always have to demand a full assignment of rights – sometimes an exclusive licence with the right to modify and sublicense is sufficient. Clearly distinguish between the rules for custom components (your code), standard components (the contractor’s libraries) and open-source components.

6. Acceptance procedure and acceptance reports

Final acceptance is the point at which you formally approve the result of the work. A well-designed acceptance procedure includes:

1. Notice of readiness from the contractor – together with documentation (test environment, instructions)
2. Acceptance testing on your side – based on the criteria set out in the agreement
3. An Acceptance Report (if you accept) or a Discrepancy Report (if you do not)
4. A deadline for the contractor to analyse discrepancies – e.g. 4 business days to classify reported defects
5. The right to challenge the classification – e.g. 2 business days to object to a defect being classified as “cosmetic”

The key problem: if the contractor unilaterally classifies defects (critical / standard / cosmetic / new requirement), you lose control over repair priorities. Negotiate a joint table of criteria as an appendix to the agreement.

7. Quality warranty and its limitations

Typical warranty period: 12 months from the production launch. However, the scope of the warranty may be narrower than it appears.

Warranty invalidation scenario: after launch, you install a new WordPress plugin yourself. The plugin conflicts with the contractor’s code. You submit a warranty claim. The response: “unauthorised modification – not covered by the warranty”. Repair cost: additional work.

Therefore, after launch, keep a record of all modifications to the website. Every change to the code or plugins made by you or a third party should be documented – so that you do not lose the warranty because of a minor modification.

8. Limitation of the contractor’s liability

A standard clause limits the contractor’s liability to the net amount of the fees. In addition, it excludes liability for loss of profits (lucrum cessans).

This is standard market practice from the contractor’s perspective, but you can negotiate exceptions. Good practice: leave infringements of intellectual property rights and serious breaches of confidentiality or security subject to unlimited liability. Even if the general liability cap is limited to the amount of the fees, these categories of breaches should be excluded from the cap.

9. Scope review clause – protection against uncontrolled cost increases

This is a mechanism for managing changes during the project. Without it, every change in scope must be negotiated from scratch – or, worse still, the contractor implements it “their way” and issues an invoice for additional work.

A well-designed clause works as follows:

1. The contractor identifies a discrepancy between the scope of the agreement and the actual complexity of the work
2. The contractor reports it in writing within 3 business days
3. The parties have 7 business days to negotiate
4. Until an agreement is reached, work on the disputed scope is suspended
5. Additional work requires a written work order specifying the budget

Without this clause: the graphic design in Figma turns out to be more complex than assumed in the estimate. The contractor either delivers a simplified version or demands an additional payment without a formal procedure. With the clause: you have time to make a decision and retain control over the budget.

10. Consequences of termination and contractual penalties

Contractual penalties should be a tool that genuinely keeps both parties accountable. A problem arises when they are asymmetrical.

An example from the agreement analysed: the penalty for the contractor abandoning the project is only zł 5,000 – for a project worth zł 27,400 net, this is less than 20% of the contract value. Restarting with a new contractor usually costs 30–50% of the project value (onboarding, recreating the work, code analysis).

What to negotiate:

1. A penalty of at least 15–20% of the agreement value for termination due to reasons attributable to the contractor
2. A source code escrow mechanism – so that if the project is abandoned, you have access to the work completed to date
3. An obligation to hand over documentation and source code regardless of the reason for terminating the agreement
4. The right to claim additional damages exceeding the contractual penalties

11. Renegotiation clause in the event of project delays

IT projects run over schedule. The question is: who pays for it?

A typical clause states that a project delay of more than 4 months for reasons not attributable to the contractor entitles the contractor to renegotiate the price. If you do not agree within 7 days, the contractor has the right to withdraw from the agreement while retaining payment for the work completed.

It is worth noting that Article 357¹ of the Civil Code (the rebus sic stantibus clause – an extraordinary change in circumstances) is exceptional in nature. A delay in an IT project does not in itself provide automatic grounds for a court-ordered price renegotiation. There must be an objective, extraordinary change in circumstances and a risk of gross loss. This is why a contractual renegotiation clause is more important than the statutory provision – because it gives both parties a predictable procedure to follow.

12. Confidentiality and data protection

A confidentiality clause usually remains in force for 5 years after the agreement ends. The content of the agreement is confidential information by definition.

A separate issue is the GDPR – if the website collects personal data (contact forms, analytics, newsletter), the agreement should include:

1. A definition of roles: who is the data controller and who is the processor
2. A personal data processing agreement (Article 28 of the GDPR)
3. An obligation for the contractor to delete the data after the work is completed
4. Procedures for responding to a data security breach

Digital accessibility – a new obligation from 28 June 2025

From 28 June 2025, the Act of 26 April 2024 on Ensuring Compliance with Accessibility Requirements (the Polish Accessibility Act, implementing EU Directive 2019/882) applies. If your website is an interface for e-commerce services (an online store, an e-commerce platform, online sales of services), it must comply with the requirements of EN 301 549 and the WCAG 2.1 Level AA standard.

Supervision is exercised by the President of PFRON, the President of UKE, the Minister of Digital Affairs (for e-commerce) and the Financial Ombudsman. Sanctions include orders to remedy a breach, bans on providing services and administrative fines.

If you are commissioning a website with e-commerce features, include WCAG 2.1 AA requirements in the project scope. Deliberately excluding accessibility from the scope of the agreement exposes you to the risk of sanctions – and the need for an expensive website rebuild after launch.

Checklist before signing a website development agreement

Before signing an agreement with a software house or web agency, go through these points:

How we can help you with an IT agreement

Reviewing agreements with software houses or web agencies is something we do regularly. We know the common pitfalls because we see them in dozens of contracts every year – from projects worth tens of thousands of złoty to implementations worth hundreds of thousands.

Our support includes:

1. Pre-signing agreement review – we identify clauses that need to be changed, propose specific wording and assist you in negotiations with the contractor
2. Audit of existing IT agreements – if you have already signed an agreement, we will check where the gaps are and how to close them with an amendment
3. Preparation of agreement templates – if you regularly commission IT services, we build a consistent system of agreements tailored to your business model
4. Support in disputes with contractors – from amicable negotiations to representation in legal proceedings

We do not create documents “just in case” – we design rules where risks actually arise. We combine contract law with copyright, the GDPR and the specific characteristics of the IT industry because these areas overlap in web development agreements.

Website development agreement – summary and next steps

A website development agreement is not a formality to be signed “so the project can begin”. It is a tool that determines whether you retain control over the budget, schedule and rights to the work product.

The 12 clauses described in this article cover six categories of contractual risk: technical, organisational, legal, financial, operational and relational. Each of them requires an informed decision – not the contractor’s default settings.

Before you sign your next agreement with a software house, send it to us for review. Specific comments, no legal jargon, and a turnaround time tailored to your schedule. Contact us

Frequently asked questions

Can I use my own lawyer to review an agreement with a software house? Yes – and that is good practice. Professional contractors treat legal review as a normal part of the process. If a software house reacts negatively to the suggestion that your lawyer review the agreement, that is a red flag. Reviewing an IT agreement usually takes 2–5 business days and can identify clauses that may cost you many times more than the legal service itself.

Is deemed acceptance legal, and can I challenge it after the fact? A deemed acceptance clause is permissible in B2B relationships between professionals – this is confirmed by case law (judgment of the Warsaw Regional Court, XXIII Ga 978/20). Once the deadline has passed, you can still report material defects discovered after acceptance – the clause cannot deprive you of this right. However, non-material (cosmetic) defects reported after deemed acceptance become additional work. It is therefore better to negotiate a realistic review deadline than to try to challenge the clause after the fact.

How much should I budget for additional work beyond the amount stated in the agreement? There is no single rule, but with a well-defined scope, a contingency of 15–20% of the agreement value is reasonable. With a poorly defined scope, additional work may exceed the value of the original agreement. Check the hourly rate for additional work in the agreement – if it is zł 250–500/h, calculate how many hours of additional work your budget can accommodate.

Is a 12-month warranty standard in the market? 12 months from the production launch is a common period in web development agreements. However, the scope of the warranty may be narrower than you expect – it covers errors in the contractor’s code, but not problems resulting from your modifications, expired third-party licences or changes to the APIs of third-party tools. Once the warranty ends, you need a separate maintenance agreement or internal resources to maintain the website.

What happens to my website if the software house goes bankrupt during the project? If copyright has not been assigned to you (because you have not paid all the instalments), you may lose access to the code. The safeguard is source code escrow – a deposit with an independent third party (a notary, a specialist escrow company or a safe deposit box) subject to specified release conditions (e.g. the contractor being declared bankrupt). In Poland, source code escrow is an innominate agreement (Article 750 of the Civil Code), used mainly in larger projects, but it is worth considering even for smaller implementations – particularly if the website is critical to your business.

How can I negotiate an agreement with a software house without damaging the relationship? Contract negotiations are a normal part of working together – not a sign of distrust. Focus on mechanisms, not emotions: propose a jointly agreed table of defect criteria instead of unilateral classification, propose a scope review clause with deadlines for both parties, and propose realistic acceptance deadlines. A professional contractor will appreciate a partner who knows what they want – because clear rules reduce the risk of disputes for both parties.