Engagement agreement template

Template published by Zapolu s.r.o. (zapolu.com) under CC BY 4.0: use it with Zapolu or with any other vendor, commercially or not, as long as the attribution at the end stays. It is a working agreement, not legal advice; have your counsel review the contractual parts. Template version 1.0, 1 August 2026. The current version is at zapolu.com/downloads.

Where this template leaves a blank, it names a recommended default or gives a worked example. Change a default deliberately where it does not fit, rather than leaving the blank empty.

1. Scope

What we are doing: one paragraph, plain language. A scope that cannot be described in one paragraph should be split into two engagements.
What we are explicitly not doing: list what a reader might otherwise assume is included.
Success criteria: measurable, agreed before work starts. Example: “checkout LCP ≤ 1.5 s at p75 on field data”, not “site feels faster.”

2. People and subcontracting

Client’s technical point of contact: name, with the authority to decide independently and an allocation of 1–2 h/week for this engagement.
Vendor engineers on this engagement: names. The engineers listed write the code and attend the meetings. Substitution requires the client’s written approval.
Subcontractors are named in advance or not used. Recommended default: none without written approval. A subcontractor is bound by every clause here, and the vendor remains liable for their work.

3. Working rhythm and transparency

Work happens in the client’s repository and organization, in small reviewable pull requests, from day one.
Weekly written check-in (shipped / next / blocked / decisions needed), delivered every week, including weeks with negative findings.
Status meetings happen only with an agenda; by default the written check-in replaces them.

4. Commercial terms

Model: fixed price / weekly-capped invoice / monthly retainer with an agreed number of hours (select one; mixed models per phase are acceptable).
Change requests are written, estimated, and approved before work begins; invoices contain no line items that were not approved in advance.
Payment terms: recommended default: 14 days net. Work pauses after written notice if an undisputed invoice is 14 days overdue.
Expenses (travel, licences, third-party services) are invoiced at cost. Recommended default: none without prior written approval.

5. Acceptance and defects

Work is accepted against the success criteria in section 1, not against opinion.
The client has recommended default: 10 business days from delivery to accept, or to state in writing which criterion is not met. The work counts as accepted after that window.
Defects present at handover are corrected at no charge for recommended default: 90 days. A change of scope is a change request under section 4, not a defect.

6. Ownership, existing rights, and exit

All code, configuration, and documentation written for this engagement belong to the client from the first paid invoice. The repository lives in the client’s organization; there is nothing to hand over at the end.
Open-source and third-party components keep their own licences. The vendor lists them, keeps them compatible with how the client uses the work, and adds no copyleft dependency to proprietary code without written approval.
Material the vendor brings with it (internal libraries, tooling, checklists) stays the vendor’s. The client receives a perpetual, transferable licence to use, modify, and sublicense it as part of the delivered work.
Either side may end the engagement with recommended default: two weeks’ written notice. The client keeps everything paid for, including work in progress.

7. Launches and rollback

Migrations and risky launches run parallel / shadow-traffic where feasible; big-bang only when there is no alternative.
A written go / no-go checklist is signed off by both sides before cutover.
A tested rollback path stays usable for 30 days after launch.

8. Incident handling

Production incidents: the party that first detects an incident opens it; the vendor responds within recommended default: 4 working hours, on business days between 09:00 and 18:00 CET. A tighter window is a paid on-call arrangement, agreed separately.
Every incident ends with a blameless written post-mortem: what happened, what was done, what changes to prevent recurrence.
Missed estimates are reported in the weekly check-in the moment they are known, together with a revised plan.

9. Access and credentials

The vendor receives the least access the work requires, requested in writing, granted by the client, and issued per person. No shared logins.
Credentials travel through the client’s secret manager or another encrypted channel, never through email or chat.
Production data is not copied to a developer machine. Where production-like data is needed, it is anonymized first.
All vendor access is revoked within recommended default: 5 business days of the engagement ending, and the client confirms the revocation in writing.

10. Confidentiality and data protection

Mutual NDA covers business data in both directions.
Where the vendor processes personal data on the client’s behalf, a written processing agreement under GDPR Article 28 applies: purpose, categories of data, security measures, and deletion at the end.
Subprocessors are listed in advance and changed only with notice, which the client may object to. The list covers everything that sees client data, including hosting, error tracking, and AI coding tools.
Processing and storage locations are named. Recommended default: EU/EEA only, or a documented transfer mechanism.
The vendor may describe the engagement publicly only in anonymized form unless the client approves naming in writing.

Version: fill in. Signed: both technical points of contact, the people doing and receiving the work, not only the people billing it.

Engagement Agreement, template version 1.0, by Zapolu s.r.o., zapolu.com, licensed under CC BY 4.0 (creativecommons.org/licenses/by/4.0/).