Nester
2026
Digital Signature: closing the contract without leaving Nester
Closing the loop on Nester's contract lifecycle — moving signing from outside the platform to a legally binding flow inside it, with parallel or sequential signers and real-time status tracking.
Context
The contract was generated inside Nester. Signing it still happened outside.
With dynamic templates already in production, the next bottleneck was obvious: contracts got built inside the platform, but signing them still meant printing, or some separate channel — no trace, no control from Nester. We integrated digital signing on top of Signaturit, so a contract could go from draft to legally binding in minutes, with owners, tenants, and guarantors signing directly from the platform.
Challenge
The hardest problem wasn't technical. It was a habit nobody had questioned.
A figure that was never properly modeled
Until this project, guarantors didn't exist as their own entity in Nester. Managers had been adding them as "just another tenant" — an improvised workaround so common it had become the standard habit for our clients, even though it was never actually correct.
Why it couldn't stay that way
To manage who signs, in what role, with what legal standing, a guarantor couldn't stay mixed in with the tenant entity anymore. Separating it meant a modeling decision with a direct impact on an already-ingrained user behavior — knowing there were mixed opinions internally about how much to disrupt that habit. It was the most expensive decision of the entire project.
Approach
Reuse what already worked. Rebuild only what was actually broken.
Guarantor as an attribute, not a new entity
The design solution: treat the guarantor as an attribute of the tenant — a 1:1, optional relationship, with no separate "person" entity in the system. That simplified the data model, but moved the complexity somewhere specific: what happens when a contract template asks for guarantor data and the selected tenant doesn't have one configured. That's where we reused the same color-validation system already built for templates — the field shows up red in the preview, solvable right there, no need to go back to the tenant's profile.
Parallel vs. sequential signing
Two different business models living on the same screen. In parallel, every signer gets the invitation at once, no hierarchy. In sequential, the system doesn't invite the second signer until the first one completes their signature; if anyone declines, the process stops and the manager gets notified.
Keeping the signing gateway with the provider, not inside Nester
A pragmatic scope decision: this first phase prioritized shipping the full surrounding functionality — setup, tracking, states, communications — and left the actual act of signing on Signaturit's platform, with the idea of bringing it into Nester later. Prioritizing "fully orchestrated" over "everything lives in our UI from day one" was the right call for this stage.
Solution
A document card that tracks a legal process end to end.
Setting up who signs, and in what order
Inside contract creation, a two-step flow: first the legal preview of the document, then signer configuration — owners, tenants, guarantors — with their signing mode and the option to require initials on every page.
From static file to live status
The Documents card evolved from a static list into a component that reflects the full signing lifecycle: no document → no digital signature → pending → issues → signed. Each state carries its own actions — for example, the file can only be deleted if it hasn't been sent for signing yet. The "issues" state — a bounced or invalid email from Signaturit — lets the manager fix the data inline and automatically retry the send, without restarting the whole process.
Reflection & what's next
Orchestration first. The signing screen itself comes later.
Keeping the actual signing act on Signaturit's side, rather than building it natively into Nester, was a deliberate trade-off — get the full flow shipped and reliable now, bring the signing experience fully in-house as a later phase.
Key Takeaway
The technical build was the easy part. Breaking a bad habit was not.
Separating the guarantor wasn't a data modeling exercise — it was asking users to unlearn something they'd been doing wrong for years, because it had always technically worked. The real lesson: the correct model and the comfortable habit are not always the same thing, and sometimes the harder product decision is the one that fixes years of quiet debt instead of shipping around it.
