SoW
Statement of Work
A signed contract that names a deliverable, a price, and a deadline, and legally binds the vendor to all three.
A Statement of Work is the document that turns a verbal agreement into a contract. It lists the deliverable in concrete terms (“feature X live on production, passing acceptance criteria A, B, C”), the price, the deadline, and the conditions for sign-off.
In Austrian and German law the corresponding instrument is the Werkvertrag, which is stronger than the English-language SoW: the vendor is legally bound to deliver the work, not just to provide effort, and the customer can withhold payment until the work is accepted. A Time & Material contract under the same legal framework is a Dienstvertrag, which only obliges effort. Wavect’s fixed-price engagements are Werkvertrag contracts.
Worked example of why the acceptance criteria carry the whole contract: an SoW that says “build the reporting feature, the feature should work well” is unenforceable, because “work well” is an opinion. An SoW that says “endpoint /reports returns the monthly figures for input range R within 200ms under load L, matching values in spec S” is testable, and “done” is no longer a negotiation. The most common founder mistake is signing a vaguely worded SoW to save time at the start, then spending six months arguing about whether a half-working feature counts as delivered. A vendor who resists writing precise acceptance criteria is protecting their right to have that argument later.
The SoW is also the document that prevents scope creep: anything not in it is by definition out of scope and gets handled with a change request. Note the layering, an MSA (Master Services Agreement) covers the legal frame (IP, liability, jurisdiction) once, and many SoWs live under it over time. The honest trade-off is that a tight SoW takes real work to write and feels slow up front, which is exactly the work a paid discovery-phase exists to do. Related: Fractional CTO Austria explains the Werkvertrag model in practice.