---
title: "Engagement agreement template"
description: "The working agreement we would sign, published under CC BY 4.0 so you can use it with any vendor: scope, cadence, ownership, incidents, access, and data protection, with a recommended default in every blank."
language: "en"
canonical: "https://zapolu.com/downloads/engagement-template/"
---

# Engagement Agreement: Working Document

> 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](https://zapolu.com/downloads/zapolu-engagement-template.pdf).

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/)._