Most European civil-law systems distinguish two primary contract forms for software delivery:
Work contract (Werkvertrag / contrat d'entreprise / contratto d'opera). The contractor owes a defined result. Compensation is typically lump-sum. Formal acceptance and defect liability are mandatory. Commercial risk sits with the contractor.
Service contract (Dienstvertrag / contrat de services). The contractor owes professional effort over a period. Compensation typically follows time spent. No specific deliverable, no formal acceptance ceremony. Commercial risk sits with the customer.
Time-and-material is usually a service contract. Fixed price is usually a work contract. The choice determines not only the price but liability, warranty, and oversight.
Fixed price works when three conditions hold: bounded scope, stable requirements, and measurable acceptance criteria.
Concretely: migration from a legacy system to a modern framework with documented functionality. A customer portal with a precise feature list and defined design language. An integration between two existing systems across a documented API.
In those projects, scope is tractable at signing. The contractor can estimate, price in headroom, and commit responsibly. The customer gets budget certainty for the fiscal year.
Contract essentials:
T&M fits where scope is genuinely open — and honestly communicated as such. Research projects with uncertain outcome. Early-stage product design before the target segment is confirmed. Stewardship of an existing product over a defined period without a new build.
The customer consciously accepts scope risk because nothing else fits. That is a clean classification, not a deficiency.
The problem arises when T&M is sold as convenience ("let's just start") in situations where scope is in fact determinable. The customer then purchases uncertainty no one needs.
For most mid-market product builds, neither extreme is optimal. Requirements evolve — pure fixed price is too rigid. But open-ended T&M is hard to justify to finance.
The compromise: a work contract divided into two-week sprint packages. Each sprint has a fixed price and defined acceptance criteria. At the end of each sprint, the customer decides whether to commission the next. Overall direction lives in a living product backlog.
Advantages:
Independent of the model, these points belong in the primary contract text, not in side letters:
Standard model: work contract, segmented into two-week sprint packages. Fixed price per sprint after joint scope definition in the online scoping session. Written acceptance criteria per sprint. Fifteen days of warranty, then optional maintenance. Source code and usage rights transfer to the customer at acceptance.
For cleanly bounded single projects — migrations, integrations, fixed-scope MVPs — whole-project fixed prices are also available. Pure T&M only by explicit customer request where scope is genuinely open, with mandatory monthly budget review.
If you are evaluating a proposal and unsure whether the proposed model fits the project, a complimentary online scoping session is the fastest path to clarity. We examine scope and recommend a contract form — even when we would not be the delivery partner in the end. Our consulting and training services are intentionally vendor-neutral in that conversation; if the project involves classical software development, we'll note that too. The related piece on nearshore software development across markets frames when sprint-package work contracts pair particularly well with distributed teams.
Yes. The belief that work contracts and agile delivery are incompatible dates from the early 2000s. Sprint packages within a work contract are standard practice today and well-recognized in jurisprudence across major European markets.
Formally the contractor. Reputable fixed-price proposals are issued only after joint scope clarification — typically a multi-hour scoping session and a written specification. Any fixed price offered without that groundwork either includes a heavy buffer or will generate change requests later.
Each change-request is a contract amendment — with its own scope, price, and schedule impact. The procedure belongs in the master contract: written request, offer within a defined window, customer decision. Without this flow, the costliest disputes arise.
In principle, no. The relevant civil-code provisions apply analogously. The decisive factor is agreed-upon quality. The more precisely requirements are specified, the clearer a defect looks. Unspecified "quality" is the single most common dispute point.
Legally a new contract; practically a clean cut with re-scoping. Our recommendation: when a T&M project enters a productive phase and scope stabilizes, transitioning to fixed price is often the cleanest exit from budget uncertainty.