Website Development Agreements in Poland: 12 Clauses to Check Before You Sign
Your developer emails to say a stage of your website is ready for review. You are at a trade fair and do not respond for a week. When you return, the site looks different from the approved mockup—but under the agreement, the stage has already been accepted without reservations. Revisions will now be billed as additional work at PLN 250 per hour.
That is how a deemed acceptance clause can operate. It is common in website development agreements, and it is only one of the provisions that can shift cost and control during a project.
We reviewed an actual website development agreement and identified 12 clauses worth examining before you commit. This guide explains what they mean for a business commissioning a website in Poland and ends with a checklist you can use in discussions with the developer.
Key terms in a Polish website development agreement
Polish law does not establish a separate category of “website development agreement.” Depending on the arrangement, a web development contract may be classified as a contract for specific work under Article 627 of the Polish Civil Code—focused on achieving a defined result—or a service agreement under Article 750—focused on performing services with due care. The distinction affects acceptance, liability for defects, and when payment becomes due.
| Term | What it means for the client |
|---|---|
| Deemed acceptance | Under the agreed clause, failing to respond within the review period can amount to unconditional acceptance, even if the work has defects. |
| Assignment of economic copyright | Determines when rights to use and control the code and design transfer to you; this need not happen when you make an installment payment. |
| Scope review clause | A procedure for handling changes or unexpected complexity before they expand the work and budget. |
| Warranty SLA | Agreed response and repair times during the warranty period, often differing by defect severity. |
| Additional work | Work outside the agreed scope, billed separately—often at a higher hourly rate. |
| Source code escrow | Depositing source code with an independent party for release under agreed conditions, such as the developer’s insolvency or abandonment of the project. |
The 12 clauses that shape the project
1. Scope of work: define what will be delivered
“A modern website with a contact form” leaves considerable room for disagreement. If the contract does not describe the expected result, a difference between your brief and the delivered site can become a dispute about what was ordered.
The scope should specify:
- Features by phase, such as graphic design, front-end development, and integrations.
- Non-functional requirements, including performance, responsive behavior, and supported browsers.
- Technologies and tools, such as WordPress, ACF PRO, or React.
- Express exclusions, such as accessibility work, SEO, or copywriting if these are not included.
A precise description also helps prevent scope creep: an uncontrolled expansion of the project and its cost.
2. Schedule: tie each stage to a measurable result
A phased schedule with dates lets you assess progress. Each stage should end with a deliverable you can inspect—for example, a completed Figma design or a working front end in a development environment.
Check your own obligations as carefully as the developer’s:
- Materials due before work starts. If you must provide desktop and mobile Figma designs two business days before the start date and do not do so, the start may move through no fault of the developer.
- Client-caused pauses. Under some contracts, a pause lasting more than 30 days can trigger a “return to project” fee charged at the additional-work rate.
Prepare the people and materials needed for each phase before its deadline arrives.
3. Fees: connect installments to deliverables
A phased payment structure might require 30% at the start, 30% after acceptance of the graphic design, and 40% after final acceptance. What matters is whether each payment corresponds to a defined event or result.
| Contract term | Question to ask |
|---|---|
| Stage payments | Is each installment linked to a specific deliverable and acceptance step, rather than general “progress”? |
| Invoice deadline | Can your payment process meet a deadline that may be as short as seven days from invoicing? |
| Payment more than 14 days late | Does the developer have the contractual option to suspend work and extend the schedule proportionately, or to terminate immediately? |
| Additional-work rate | Is there a separate rate, including an after-hours rate that may be twice the standard one? |
The numbers can change the economics quickly. On a project priced at PLN 27,400 net, 55 hours of additional work at PLN 500 per hour adds PLN 27,500—roughly doubling the original budget.
4. Deemed acceptance: silence can close a review stage
A typical clause gives you, for example, five business days after the developer reports that a stage is ready to submit comments. If you do not respond, the contract treats the stage as accepted without reservations. Final acceptance may allow longer—for example, ten business days—but use the same mechanism.
The approved source cites a Warsaw Regional Court decision (XXIII Ga 978/20) upholding a clause under which a business client had five business days to object and otherwise accepted the work. The court connected the client’s silence with its actual use of the work.
To manage this risk:
- Assign an internal owner to review every stage.
- Set a reminder at least two days before the response deadline.
- Negotiate enough review time for the deliverable; five business days may be too little for a 15-page site with integrations.
- Make sure acceptance does not prevent you from reporting defects discovered afterward.
Do not rely on someone noticing the notification email. Build the review period into your project plan.
Contact us if you need help reviewing an acceptance clause.
5. Copyright: establish what rights you receive, and when
Under Poland’s Copyright and Related Rights Act, an agreement obligating a party to assign economic copyright generally transfers those rights when the work is accepted, unless the parties agree otherwise. Website contracts often do agree otherwise: a clause may delay transfer until the final installment has been credited to the developer’s account.
Before that point, the client may have only a limited license—for instance, permission to test the site in a development environment. Consider the practical effect:
- You pay the first two installments, totaling approximately PLN 16,000 net.
- The site runs in the development environment.
- A dispute arises about the final phase, so you withhold the third installment.
- The economic copyright has not transferred; you have only the testing license.
- The developer may prevent the production launch.
Negotiate the rights you need to avoid that impasse. An assignment of copyright must be in writing to be valid; an oral agreement to assign it is invalid. The contract should also identify the permitted fields of exploitation—the specified ways in which the work may be used.
Consider a dispute or emergency mechanism, such as a license paired with source code escrow and clear release conditions. A full assignment is not always necessary: an exclusive license that permits modification and sublicensing may be sufficient for your business. Address custom code, the developer’s standard libraries, and open-source components separately rather than treating every component as if it carried the same rights.
6. Acceptance procedure: agree how defects are recorded
Final acceptance is the formal decision on whether to accept the completed work. A usable procedure should set out:
- How the developer gives notice of readiness, including access to the test environment and instructions.
- How you conduct acceptance tests against contractual criteria.
- How the parties record acceptance—or list discrepancies if you do not accept.
- How long the developer has to analyze reported issues, for example, four business days.
- How quickly you can challenge a classification, for example, two business days if an issue is labeled “cosmetic.”
The distinction between a critical defect, standard defect, cosmetic defect, and new requirement affects both repair priority and price. If the developer alone assigns those labels, you lose influence over the outcome. Attach a jointly agreed table of classification criteria to the contract.
7. Warranty: check its coverage, exclusions, and service times
A commonly used contractual warranty lasts 12 months from production launch. Its coverage may be narrower than the headline period suggests.
| Potentially covered | Common exclusions |
|---|---|
| Errors in code written by the developer | Problems caused by your changes to the code |
| Critical failures, with terms such as an eight-hour response and repair within two business days | Expired third-party licenses, such as ACF PRO |
| Standard and cosmetic defects, usually with longer repair periods | Changes to third-party APIs |
| Conflicts caused by plugins installed by you or another party |
For example, you install a WordPress plugin after launch. It conflicts with the developer’s code, and the developer treats the fix as outside the warranty because of the modification. The repair is then billed as additional work.
Keep a record of every post-launch change to code and plugins, including changes made by third parties. The record helps establish what caused a problem and reduces the risk of a minor modification becoming an argument over warranty coverage. Also decide who will maintain the site after the warranty ends.
8. Liability cap: identify what should sit outside it
A developer’s contract may cap liability at the net contract fee and exclude liability for lost profits (lucrum cessans). That allocation favors the developer, but exceptions can be negotiated.
Consider excluding intellectual property infringements and serious confidentiality or security breaches from the general cap. If these risks matter to your business, specify the exceptions expressly rather than assuming a general liability clause addresses them.
9. Scope review: require a decision before extra work begins
A scope review clause gives both parties a process when actual work differs from the assumptions behind the agreed price. One proposed mechanism is:
- The developer identifies a mismatch between the agreed scope and the work’s actual complexity.
- The developer reports it in writing within three business days.
- The parties have seven business days to negotiate.
- Work on the disputed element is paused until they agree.
- Additional work requires a written order with a specified budget.
Suppose the Figma design proves more complex than the estimate allowed. Without a process, the developer may simplify the build or demand more money without an agreed decision point. With one, you can choose how to proceed before the budget changes.
10. Termination and contractual penalties: plan for an unfinished project
Contractual penalties should give both sides a meaningful incentive to perform. Check whether they are proportionate.
In the agreement reviewed, the penalty for the developer abandoning a PLN 27,400 net project was PLN 5,000—less than 20% of the contract price. Restarting with another developer can cost 30–50% of the project value through onboarding, reconstruction of work, and code analysis.
Points to negotiate include:
- A penalty of at least 15–20% of the contract value if the contract ends for reasons attributable to the developer.
- Source code escrow so completed work can be accessed if the project is abandoned.
- Handover of documentation and source code, regardless of why the contract ends.
- An express right to seek additional damages above the contractual penalty.
A penalty alone does not keep the project running. Access to usable work and documentation is just as important.
11. Delay-related renegotiation: read the trigger carefully
Some contracts allow the developer to renegotiate the price if the project extends by more than four months for reasons not attributable to the developer. Under the example clause, if the client does not agree within seven days, the developer may withdraw while retaining payment for work performed.
Article 357¹ of the Polish Civil Code, often referred to as rebus sic stantibus, concerns an extraordinary change in circumstances. It is exceptional: an IT project taking longer does not automatically justify court-ordered price renegotiation. The source describes a need for an objective, extraordinary change and a risk of gross loss.
That makes the contractual mechanism especially important. Check what counts as a delay, who caused it, what notice you receive, and what happens if no new price is agreed.
12. Confidentiality and personal data: address both separately
A confidentiality clause often lasts five years after the contract ends. The agreement itself is commonly defined as confidential information.
Personal data requires a separate analysis. If the website collects data through contact forms, analytics, or a newsletter, address the GDPR in the project documents. In particular, specify:
- Who acts as controller and who acts as processor.
- Whether an Article 28 GDPR data processing agreement is needed.
- The developer’s obligation to delete data after the work ends.
- The procedure for a data security breach.
Digital accessibility: include it in relevant website briefs
Since June 28, 2025, Poland’s Act of April 26, 2024 on Ensuring Compliance with Accessibility Requirements—the Polish Accessibility Act implementing EU Directive 2019/882—has applied. The approved source states that a website serving as an interface for e-commerce services, such as an online store, e-commerce platform, or online sale of services, must meet EN 301 549 and WCAG 2.1 Level AA requirements.
The source identifies the following examples of covered services and exclusions:
| Examples identified as covered | Examples identified as excluded |
|---|---|
| Online stores and e-commerce platforms | Microenterprises with fewer than 10 employees and turnover below the EU threshold |
| Websites selling services online | Informational company websites with no ability to enter into contracts |
| Retail banking and telecommunications services | Maps and geoportals where address details are available digitally |
The authorities identified in the source include the President of PFRON, the President of UKE, the Minister of Digital Affairs for e-commerce, and the Financial Ombudsman. Measures can include orders to remedy a breach, bans on providing services, and administrative fines.
If you are commissioning e-commerce functionality, put WCAG 2.1 AA requirements into the scope and acceptance criteria. Excluding accessibility while ordering a service to which those requirements apply creates a risk of sanctions and an expensive rebuild after launch.
Pre-signing checklist
Take these questions to your meeting with the developer or web agency.
| No. | Check | Why it matters |
|---|---|---|
| 1 | Is the scope described by features and requirements, not broad labels? | Vague descriptions invite disputes and additional-work charges. |
| 2 | Does each stage have a date and measurable deliverable? | Milestones make progress assessable. |
| 3 | Are installments linked to acceptance of identified results? | Paying merely for “progress” reduces control. |
| 4 | Is each review period realistic for the deliverable? | Five business days may not be enough for a complex site. |
| 5 | Will economic copyright transfer no later than payment of the final installment? | A later transfer can leave you without control of the code. |
| 6 | Is the copyright assignment in writing, with fields of exploitation specified? | A non-written assignment is invalid. |
| 7 | Are defect categories determined using agreed criteria? | Unilateral classification lets the developer control repair priorities. |
| 8 | Is there a scope review procedure with deadlines and written approval for extra work? | It creates a decision point before cost increases. |
| 9 | Is the penalty for abandonment proportionate to the project value? | PLN 5,000 on a project of about PLN 27,000 may not cover restarting it. |
| 10 | Do you know which materials you must provide and when? | Late inputs can delay the project at your expense. |
| 11 | Does the contract say who maintains the site after the warranty? | A 12-month warranty does not provide indefinite support. |
| 12 | Are GDPR and, where applicable, WCAG 2.1 AA requirements covered? | Missing requirements can lead to compliance risk and costly rework. |
How we can help with an IT agreement
We regularly review agreements with software houses and web agencies, from projects worth tens of thousands of Polish złoty to implementations worth hundreds of thousands. Our work includes:
- Review before signing: identifying provisions to change, proposing wording, and supporting negotiations.
- Audit of an existing agreement: finding gaps and considering whether an amendment can address them.
- Contract templates: creating a consistent set of terms for businesses that regularly commission IT work.
- Dispute support: assisting with settlement discussions and representation in proceedings.
Website agreements bring contract terms, copyright, personal data, and technical delivery together. We focus the documents on the points where those risks arise.
Next steps
A website development agreement is more than permission to start building. It determines how you approve work, control changes and costs, obtain rights, and respond if delivery goes wrong. The 12 clauses above address technical, organizational, legal, financial, operational, and relationship risks; none should be left to the developer’s default wording without review.
Before signing your next agreement, contact us for a practical review and proposed changes.
Frequently asked questions
Can my own lawyer review the developer’s agreement?
Yes. Legal review is a normal part of a professional procurement process. A negative reaction from the developer is a warning sign. An IT agreement review typically takes two to five business days and can identify provisions with costs far greater than the review itself.
Is deemed acceptance permitted, and can I object afterward?
The Warsaw Regional Court decision cited above (XXIII Ga 978/20) supports the effectiveness of such a clause in a business-to-business relationship. The approved source states that you may still report material defects discovered after acceptance and that the clause cannot remove that right. It also warns that non-material, cosmetic issues raised after deemed acceptance may be treated as additional work. The safer approach is to negotiate a workable review deadline and respond within it.
How much should I allow for additional work?
There is no universal figure. For a well-defined scope, a contingency of 15–20% of the contract value is reasonable; poorly defined work can generate extras exceeding the original price. At PLN 250–500 per hour, calculate in advance how many out-of-scope hours your budget can absorb.
Is a 12-month warranty typical?
Twelve months from production launch is common in website development agreements. Check coverage as well as duration: the warranty may cover the developer’s code errors but exclude your modifications, expired external licenses, and changes to third-party APIs. Arrange maintenance or internal support for the period after it expires.
What if the developer becomes insolvent during the project?
If the agreement delays assignment of economic copyright until all installments are paid, you may lack both rights and access to the code when work stops. Source code escrow can provide for deposit with an independent party—such as a notary, specialist escrow provider, or safe-deposit facility—and release on specified events, such as the developer being declared bankrupt. In Poland, the source describes code escrow as an unnamed contract under Article 750 of the Civil Code. It is used mainly for larger projects but is worth considering for a smaller website that is critical to your business.
How can I negotiate without damaging the relationship?
Treat the discussion as project planning. Propose shared defect criteria instead of unilateral classification, a scope review process with deadlines for both parties, and acceptance periods that match the work. Clear procedures reduce the risk of disputes for both client and developer.