How should the implementation scope be defined?
A general promise to implement a system according to the customer's needs is not measurable. The agreement should identify the specification, processes, integrations, architecture, migration format and deliverables for each stage.
Pricing assumptions and exclusions are equally important. They distinguish a defect in an agreed feature from a later extension of the project.
How should the timetable reflect customer dependencies?
Analysis, configuration, development, migration, testing, training and go-live should end in defined outputs. The timetable must identify data, decisions, environments and access to be supplied by the customer.
A customer delay should not permit any timetable extension without explanation. The supplier should notify the obstacle, its impact and available mitigation.
How should acceptance and defects work?
The procedure should define the test subject, criteria, reporting period and retesting. Blocking, material and minor defects can be treated differently.
Not every issue should block an entire milestone, but the supplier should not receive full payment for a solution whose core functions fail. A rejection should identify the specific deviation from the specification.
Why is a change-request process essential?
Change is normal; starting it without agreeing price, time and architecture impact creates the problem. The process should cover the request, analysis, quotation, authorised approval and treatment of work already in progress.
The parties may also define a limited allowance for minor modifications included in the base fee.
Which pricing model fits the risk?
Fixed price requires a mature scope. Time and materials requires time reporting, budget limits and control of extra work. A mixed model can use fixed fees for defined stages and hourly billing for changes.
Payments should follow measurable outputs so that neither a high advance nor payment only after go-live allocates risk disproportionately.
How should software and component rights be allocated?
A solution usually combines bespoke work, supplier background technology, third-party products, open source and cloud configuration. The agreement should say which layer is assigned and which is licensed.
Under Polish law, a copyright assignment requires written form and identification of the fields of exploitation. Paying an invoice does not automatically transfer code rights, and the supplier should hold a complete chain of title from its team.
How should data, security and support be structured?
Before production data is used, the parties should allocate GDPR roles, environments, access, subprocessors, incidents, backups and deletion. Processing on the customer's behalf requires Article 28 GDPR terms.
Defect warranty, maintenance and SLA serve different purposes and should distinguish non-conformity, product development and operational support.
What should the exit plan cover?
The agreement should require delivery of data, configuration, code covered by the relevant rights, documentation and administrator access. Export format, timing, migration cost and cooperation with a replacement supplier matter in practice.
For critical systems, the parties may consider a customer-controlled repository, recurring documentation delivery or source-code escrow.
How the issue appears in practice
Hypothetical example: three integrations added without change control
The specification includes one accounting integration. During the project, the customer adds warehouse, courier and foreign-group systems, and the team starts work based on meeting notes. At acceptance, the supplier claims extra fees and time while the customer treats the integrations as included. A formal impact analysis before work began would have aligned scope, architecture, price and delivery.
Matters to determine or verify before proceeding
- Specification, assumptions, exclusions and integration ownership
- Milestones, dependencies and customer cooperation
- Acceptance criteria, defect classes and retesting
- Change-request process and authorised approvers
- Pricing model, time reporting and budget limits
- Rights to code, third-party components, open source and documentation
- Personal data, security, SLA and incident response
- Data export, documentation and supplier transition support
Key issues at a glance
| Issue | Key information |
|---|---|
| Scope | Measurable deliverables, integrations, assumptions and exclusions |
| Acceptance | Test criteria, defect classes, deadlines and retesting |
| Change | Price and timetable impact agreed before additional work |
| IP | Bespoke work separated from background and third-party licences |
| Exit | Data, documentation, access and practical migration support |
Legal basis
- Polish Civil Code of 23 April 1964, in particular the rules on performance and contractual liability
- Polish Copyright and Related Rights Act of 4 February 1994, in particular Articles 41, 53 and 74
- Regulation (EU) 2016/679, in particular Articles 28 and 32
This article provides general information and does not constitute legal advice for a specific matter. The appropriate solution depends on the facts, documents and business objective.
Summary
An implementation agreement should let the parties distinguish a defect from new scope, run objective acceptance and continue using the solution after the supplier relationship ends. Its legal mechanisms must remain consistent with the specification and the way the project is actually delivered.