Nester
2026
Contract Templates: one document that adapts to any contract
Redesigning how Nester generates, validates, and legally signs a lease agreement — replacing a static PDF upload with a dynamic template engine built for contracts that are never the same twice.
Context
A contract is Nester's core. It was also its most rigid part.
The only option was uploading a PDF drafted outside Nester — no editing, no viewing, no deleting from inside the platform. It was a dead file attached to a record, disconnected from the owner, tenant, and property data the system already had.
Property managers rebuilt the same document over and over, copying data the platform already stored. Agencies and family offices running 10+ templates asked for this constantly. It wasn't a nice-to-have — it was a basic the industry expected, and we hadn't shipped it yet.
Challenge
One template had to survive contracts that are never the same twice.
A number that's never fixed
A contract can have one owner or five. One tenant or five. One property, or several. That number is only known when the manager fills out the contract — never when the template is created. Design for a fixed number of parties, and the first contract that didn't fit the mold would break it.
Designing inside a moving stack
Part of the front-end still runs on Laravel with Bootstrap 4, mid-migration to Next.js. That shaped real decisions — TipTap for the rich text editor, and variables built as atomic nodes (chips), not plain text, so behavior stayed predictable inside the current stack's limits.
Approach
Two systems, one source of truth.
Smart blocks vs. indexed variables
I designed two systems that coexist. Smart blocks: the manager writes the text once for "one" owner, tenant, or property, and the system automatically iterates over every real record in the contract, concatenating them with correct grammar. Indexed variables (1 through 5): for cases where order matters and parties aren't listed consecutively — "owner 1 hands over the keys, owner 2 receives notifications." Both draw from the same data source; the only difference is how that data gets traversed. This was the decision that took the most iteration — it had to work, but it also had to be legible to a non-technical user drafting a legal document.
Configuring smart blocks for owners, tenants, and properties — one system, three contexts.
A color code so a legal document never ships half-done
Every variable resolves against real data at contract creation, marked blue (existing data, editable), yellow (custom variable), or red (required, missing). The product decision behind it: the contract can't be accepted while red fields remain. A legal document with gaps isn't a UI bug — it's real business risk.
The contract preview — blue for existing data, yellow for custom variables, red for what's still missing.
A menu that doesn't interrupt drafting
Inserting a variable normally closes the menu. We kept it open instead, so a manager could insert name, ID number, and address back to back without reopening the command each time.
Seven categories, one slash-menu away — no need to hunt for a variable.
Solution
Build once. Reuse in every contract.
The template editor
A document-style editor (TipTap), with variables organized into 7 categories — property, owners, tenants, contract terms, financials, extras, and smart blocks — plus the ability to create custom variables and categories when the system doesn't already cover something.
The template editor, with page-level settings — logo, numbering — configured right alongside the content.
From template to signed-ready contract
At contract creation, the manager picks a template or uploads a PDF. Choosing a template opens the dynamic previewer with the color system above, letting the manager resolve any pending field directly on the document — no need to leave the preview.
Reflection & what's next
The adoption answered the question we couldn't ask directly.
60 distinct contract templates were created in the first two months after launch — a clear signal the problem was real: managers didn't just adopt the feature, they actively customized it to their own operation, across rental types, regions, and client profiles.
Key Takeaway
The hard part was never making it work. It was making it legible.
Smart blocks and indexed variables both do the same technical job: resolve data into text. The real design challenge was building something a non-technical person could trust with a legal document — visible, editable, and safe to get wrong before it ever gets signed.
