Inside the Build: 4 Simple Steps to Automate a Rental Contract

Here is how we automate a rental contract for a property law firm that used to draft every lease from memory. Drafting a compliant residential lease in Germany is not a fill-in-the-blanks job. The rent adjustment clause alone has several legally distinct variants, and picking the wrong one, or forgetting a clause a property genuinely needs, is the kind of mistake that only shows up later.

This is the story behind one of the case studies on the case studies page. What the process looked like before, what got built, and why the automation deliberately stops short of making any legal decision itself.

What Was Actually Slow About Drafting a Lease

The slow part was never the typing. It was reassembling the same structure every time: the landlord and tenant details, the property facts, and then a set of legal clauses that change depending on the situation. Is the rent index-linked or staggered? Is subletting allowed, and under what conditions? Which cosmetic-repair clause applies to a renovated unit versus an unrenovated one? Each of those is a real legal judgment call, not a fact that can be looked up.

Why the Software Doesn’t Make Legal Decisions

The build is deliberately split into two stages that map onto who actually owns each decision. A client-facing form collects the facts: the property, the parties, the dates, the rent. That is genuinely just data entry, and automating it removes nothing anyone would want to keep doing by hand. A second form, filled in separately by the reviewing lawyer, captures the legal decisions: which clause variant applies, whether a rent-brake exception is documented, how liability is limited. The system merges both into a lawyer-approved template. It renders the document. It does not decide what the document should say.

How the Two-Stage Intake Actually Works

Once a client submits the facts form, a summary is emailed straight to the firm so nothing sits waiting to be checked manually. The lawyer’s clause decisions and the client’s facts are then merged into a single Word template built with real, conditional legal-clause blocks. The document generation uses the open-source python-docx library, and each clause block is either filled in or removed entirely, never left behind as an empty placeholder in the final document. The finished, ready-to-sign lease is generated and stored automatically, with nothing left to retype.

What It Actually Takes to Automate a Rental Contract Like This

Building a system like this starts with the clause library itself, not the software. Every legal variant the firm actually uses, each rent-adjustment type, each version of the cosmetic-repair clause, every subletting condition, has to be captured as a real, reviewable block in the template before any code touches it. That part is genuinely a lawyer’s work, not a developer’s. Once the clause library exists, wiring the two intake forms and the document generation around it is comparatively fast, because by then every decision the system needs to make has already been made by a person who is actually qualified to make it.

Why This Kind of Split Matters Beyond Contracts

The same pattern shows up anywhere a document depends on both facts and judgment: insurance paperwork, procurement contracts, compliance filings. It is the same principle behind keeping one source of truth for a customer record instead of letting every system hold its own version. The mistake worth avoiding is automating the whole thing end to end and quietly baking someone’s professional judgment into code that nobody reviews again. Splitting facts from judgment keeps the judgment visible, reviewable, and in the hands of the person actually qualified to make it, while the automation only ever does the part that was never a judgment call in the first place.