Building A-du: Part Four

The problem

A lease is a contract. That sounds obvious until you watch how most rental platforms handle it. The common pattern is: the landlord generates a PDF, emails it to the tenant, asks them to print, sign, scan, and send it back, and uploads the result somewhere. At every step, the lease exists in inconsistent states across two inboxes and three filesystems. If something goes wrong, and something always does, you're trying to reconstruct the truth from a chain of email attachments six months later.

I didn't want A-du to be that platform. I wanted a flow where the lease exists as a single object, signed by both parties through a real e-signature service, with the executed PDF archived in the platform, and the whole sequence visible inside one workflow. From "tenant accepted" to "both parties signed," all in one place.

There's also a thing that almost every rental platform misses: landlords routinely want to add something to a lease after it's been generated. Pet rules. House rules. Specific maintenance covenants. Sometimes those have to be a separately signed addendum. The platform has to handle that case without making the addendum disappear into an inbox.

What we built

Lease generation and signing run through Anvil, a focused e-signature service that's good at exactly this. It takes a template, populates it from data, and walks two parties through a signing flow that holds up legally.

The flow on A-du Rent looks like this:

A landlord initiates a lease from inside the platform. We assemble the data (the listing, the reservation, the tenant, the agreed terms) and Anvil produces a signing-ready document. Both parties sign through Anvil's hosted signing experience, embedded in the platform so the tenant doesn't have to bounce to a third-party site they've never seen. As each signature happens, A-du is notified and updates the lease record. Once both parties have signed, we pull down the executed PDF and the signing certificate, and store them privately in the platform so the landlord and tenant can each pull up their copy from their dashboard.

There's no version of the lease that lives only in someone's email. There's no half-signed PDF floating around as a separate file. There's one object, and it has the right state at any given moment.

Now the addendum part.

A landlord may need to add something to a signed lease: a pet rule, a parking rule, a lawn-care covenant, a specific clause about a shared driveway. The right way to handle that is not to re-issue the whole lease. It's to issue a separately signed addendum, what we call a supplemental document, that the tenant has to sign before move-in becomes final.

We treat supplementals as a first-class part of the lease workflow. Each one is its own signed document with its own record. The tenant sees their pending supplementals in their dashboard, and (this is the part that matters) the platform will not let the tenant complete their final move-in payment until every supplemental on their lease has been signed. The unsigned addendum is unmissable.

That's a small piece of design with a big consequence. Pet addendums and house rules are, in my experience, where the substantive covenants on a lease actually live. Burying one in an email attachment is how a tenant ends up six months later filing a maintenance complaint about something they legitimately didn't know about. The platform shouldn't let that happen.

What it means for you

If you're a landlord, you generate a lease in A-du, both parties sign through Anvil, and you get the executed PDF and signing certificate in your records automatically. If you need to add an addendum after the fact (a pet rule, a parking rule, anything), you do it as a supplemental, and the platform refuses to let the tenant finalize move-in until the supplemental is signed.

If you're a tenant, you sign your lease and any supplementals from inside A-du, with the document hosted by Anvil, the same way you've signed paperwork to close on a house or open a brokerage account. You can pull up your executed lease from your dashboard whenever you want. Nothing about the process requires you to print, scan, or attach anything to an email.

This doesn't change pricing. The first 100 landlords on A-du Rent still pay no platform fees for life. Lease generation is part of what we do for you, not an upsell.

What I learned

The biggest lesson here was about state. A lease can be in a surprising number of states: draft, out for signature, partially signed, fully executed, superseded, cancelled. A lease with supplementals adds another axis on top. If you treat any of those as a single yes-or-no flag, you'll be wrong somewhere within a week. We modelled each transition explicitly, with its own timestamp, and the platform reads from those records rather than guessing. It's slightly more verbose. It's also debuggable the next time something looks off.

The second lesson was about treating webhooks (the messages our e-signature partner sends us when something happens on their side) as instructions to check state, not to change it unconditionally. Every notification asks: "is this transition still meaningful given what we already know?" before it acts. If we get a duplicate notification, and you always do eventually, we shrug and move on. That single discipline saved us during a partner-side rewrite midway through the project, and it has saved us several times since.

A third thing, which is mostly about taste: building the supplementals workflow as a separate thing on top of leases, rather than shoving addendums into the same lease document and re-issuing, was one of the more important calls we made. The re-issue path would have been faster to ship and worse for everyone forever. The right model is the one that matches what the user is actually doing, which is adding a thing on top of an existing thing. That took its own careful piece of work to express.

---

Next in the series: what we did when we realized we'd been calling our customers the wrong word, and why renaming "homeowner" to "landlord" across the platform was worth doing properly.