BuildAgreement returns the agreement as structured sections, each flagged for whether it must be initialed, with headings numbered dynamically at assembly so conditional sections never break the numbering. When named-competitor exclusivity is purchased, a dedicated section lists each protected competitor by name with grant, scope and termination terms. The signed copy is a print-ready branded document with per-section initials and a signature block.
Also called: service agreement · sign up contract · exclusivity agreement · what am I agreeing to
- 1The order block fills from the selected plan; the exclusivity section is conditional on the purchase.
- 2Each important clause is individually initialed, then a final checkbox plus typed name plus drawn signature is captured.
- 3At signing the checkout route serialises the agreement into the signup record: 'the signed copy is rendered from THAT snapshot forever, so edits to this file never rewrite signed history.'
- 4Competitors added after signing get an append-only addendum entry carrying the full scope and term language, 'WITHOUT rewriting the frozen signed contract_document'.
- 5The signed document renders light-themed and print-ready with a 'Download / print PDF' action.
The freeze and the addendum mechanism exist for the same reason as the builder-facing contract engine: once signed, a document is evidence. The exclusivity terms are deliberately a single source of truth — 'ONE source of truth, used both inline in buildAgreement's signed contract AND by post-signup additions' — so a competitor added later still carries full scope, promise, term and remedy language.
- Signup terms that can't be produced later
- Post-signup additions with no legal language behind them
- Rewriting a signed agreement to record a later change
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →