SOW Template Generator
Generate a SOW (Statement of Work) template with sections for scope, deliverables, timelines and payment. Formalize projects with clients and vendors.
SOW Markdown
—
SOW: the legal contract that turns a project into deliverables
A SOW — Statement of Work — is the legal contract that translates a project into enumerated services, deliverables, timeline and cost. It lives at the intersection of legal, sales and project management, and shows up everywhere consulting, freelance or agency work is bought. The SOW is the document a court would read to decide whether the contractor actually shipped what was agreed.
A defensible SOW always has: Project scope (deliverables enumerated, not paraphrased); Timeline (milestones with dates); Cost (fixed price or T&M — Time & Materials); Acceptance criteria (the explicit definition of done); Change request process (how scope changes get approved and repriced); Payment terms (Net 30 is the default); IP ownership (work-for-hire vs creator retains); and a Termination clause. A clean "out of scope" section is the cheapest insurance against scope creep that you will ever buy.
SOW vs MSA vs PO: what each contract actually does
An MSA (Master Services Agreement) is the umbrella contract — once a year, signed once, governs the relationship. The SOW is one specific project executed under the MSA: same parties, narrower scope, separate signatures. A PO (Purchase Order) is simpler, designed for goods, and is what procurement issues against a SOW to release payment. Mature B2B relationships layer all three: MSA at the top, multiple SOWs over time, each one paid via its own PO.
Pricing models and the Brazilian legal context
Common pricing models: fixed price (works when scope is genuinely clear), T&M (hourly billing — buyer wears the risk), milestone-based (payment per deliverable), retainer (fixed monthly fee for ongoing services). In Brazil the SOW maps onto the "Contrato de Prestação de Serviços" — governed by Civil Code articles 593–609. Tax compliance matters: ISS retention at the municipal level, NFS-e (electronic service invoice), and RPA (Recibo de Pagamento Autônomo) for individual contractors. Bilateral, bilingual headers are common when one side is international.
Tooling, e-signature and clauses you should not skip
Tooling: PandaDoc and HelloSign (now Dropbox Sign) for e-signature plus template libraries; DocuSign is the legacy enterprise default; Bonsai targets freelancers with bundled SOW + invoicing. Clauses people forget but later wish they hadn't: an IP ownership clause (default to work-for-hire if the client paid for it); a separate NDA — Non-Disclosure Agreement — kept outside the SOW so it survives termination; and an indemnification clause that bounds liability if something goes wrong downstream.
FAQ
Does an SOW replace the contract? No — the SOW is part of the contract package. It either stands alone as the full contract for a small engagement, or sits under an MSA for a recurring relationship.
Is e-signature legally valid in Brazil? Yes. Provisional Measure 2.200-2/2001 established ICP-Brasil and recognizes electronic signatures; for most B2B SOWs a simple e-signature (DocuSign, PandaDoc) is sufficient and enforceable.
Should the SOW be bilingual? If one of the parties is foreign — yes. Two columns, Portuguese on the left and English on the right, with one of the languages declared the controlling language in case of dispute.
Fixed price or T&M? Fixed price when scope is well-defined and the contractor can absorb estimation risk. T&M when discovery, research or production support means the team genuinely cannot estimate up front — and the client trusts the contractor enough to wear the variance.
Related Tools
Daily Reflective Journal Template
Generate a reflective daily journal template with gratitude, daily focus, energy level and evening reflection. Build the journaling habit and well-being.
.env File Generator by Stack
Creates complete .env and .env.example files for common stacks (Next.js, Django, Rails, Laravel, Vite) with placeholders and documented comments.
ADR Template Generator
Generate an ADR (Architectural Decision Record) template in the Michael Nygard format to document architecture decisions: context, decision and consequences.
PRD Template Generator
Generate a PRD (Product Requirements Document) template with problem, users, metrics and scope. Structure your product requirements and align your team.
RFC Template Generator
Generate an RFC (Request for Comments) template to propose and discuss technical decisions in your team. Structure context, proposal and alternatives.
CONTRIBUTING.md Generator
Generate a complete CONTRIBUTING.md for your repository, with rules for issues, pull requests, code style and conduct. Standardize how people contribute.