# Building Lease Drafting on Claude: What You Actually Have to Build Blog | LeasePilot [Blog](/blog)Industry Insights # Building Lease Drafting on Claude: What You Actually Have to Build Legal teams are increasingly asking whether they can build lease drafting on Claude directly. Here's the work that doesn't show up in the demo — and why most of it isn't a legal team's job. ![Lior Kedmi](/_next/image?url=%2Fleadership%2Flior-kedmi.jpg&w=3840&q=75&dpl=dpl_2uqrzvFtdfjJy2rKqbPgTzBd5aYQ) Lior Kedmi CTO May 22, 20268 min readCopy link TL;DR Spinning up Claude takes an afternoon. Making it draft a 60-page lease your team will actually sign takes a year and a small platform team. Here's the build tax most demos hide. § 01 ## [You're not the only team trying this](#youre-not-the-only-team-trying-this) A few weeks ago, David — my co-founder — mentioned two conversations he'd had with separate in-house legal teams. Both were quietly building lease drafting on top of Claude. Both, independently, said they assumed they were outliers. They weren't. The pattern is consistent enough that it's worth writing down. Legal teams with engineering-adjacent talent, an Anthropic enterprise subscription, and a backlog of drafting work they can't get a vendor to solve. They look at the API, look at the cost, and decide they can build it themselves. This post is what I would have wanted to read in month three of one of those projects. It's not an argument against Claude. Claude is excellent software. It's an argument about which problems you can solve by typing into it, which ones require a few months of engineering, and which ones turn into a platform-team commitment most legal departments don't realize they're signing up for. § 02 ## [What Claude is genuinely good at, in a legal context](#what-claude-is-genuinely-good-at-in-a-legal-context) Worth saying up front, because the rest of the post is going to read as skeptical and that skepticism only earns its keep if it's grounded. Claude is a strong general-purpose model. The teams I've seen get real value out of it are doing one of these things: - **Non-CRE drafting.** NDAs, vendor MSAs, employment letters, internal memos. Short, lower-stakes, mostly self-contained. - **Document Q&A across an executed-lease corpus.** "What's the renewal option in the Building 14 master lease?" An LLM with retrieval gets there fast. - **First-pass clause variations for negotiation prep.** Three fallback positions on a co-tenancy provision, ranked by aggressiveness. - **Abstraction.** Pulling key terms out of a signed lease into a structured summary. - **Comparison.** Diffing two redlines and explaining what shifted. These are tasks where probabilistic output is the right shape — an LLM produces the most-likely next word given the context, which is great for language and unreliable for arithmetic and structured rules — and where a human is checking the output for plausibility, not signing it as a binding 60-page commitment. If the work you want Claude to do lives in that list, the rest of this post does not apply to you. Build it. It'll work. § 03 ## [The architecture you actually have to build](#the-architecture-you-actually-have-to-build) The first draft of a lease drafting tool on Claude takes an afternoon. A prompt, an API call, a Word output, a screenshot to send around. That demo is the reason these projects start. The version an attorney can actually sign their name to does not take an afternoon. It takes a platform engineering project most legal teams don't realize they're committing to. Roughly, it involves the following layers, each one its own workstream: - **Retrieval.** A searchable index of your clause library, your fallback positions, your state-specific provisions, your portfolio-specific deal terms. Someone has to load it, version it, and decide what happens when two clauses overlap. The standard pattern is called retrieval-augmented generation, or RAG — feeding the model only the parts of your document corpus that are relevant to the question. Without it, the model is guessing from its training data, which is not your data. - **Prompt engineering.** System prompts that encode your drafting standards. These get long, brittle, and undocumented within three months. Six months later, the person who wrote them has left, and nobody on the team understands why the model behaves the way it does. - **Calculation.** You cannot ask Claude to compute a rent schedule, a CAM (Common Area Maintenance) reconciliation, a percentage rent breakpoint, or any other piece of arithmetic embedded in the lease. You have to wire in deterministic calculators and stitch their output into the document. Now you're maintaining two systems and a contract between them. - **Document shape.** A lease is not a blob of text. It has redlines, comments, signature blocks, defined terms with cross-references, exhibits, schedules, and a Word-shaped final form. The model produces prose. Turning that prose into a document is a separate engineering project. - **Evals.** Regression tests that score the model's output against a known-correct set, the way unit tests score a function's behavior. Without these, you have no way to detect that the model degraded after a prompt change or an Anthropic model upgrade. You will not feel the regression. Your tenants will, two years from now. - **Integration.** Yardi, MRI, your CRM (Salesforce or Microsoft Dynamics), your DMS (iManage or NetDocuments), your identity provider (Okta or Azure AD), your eSignature provider (DocuSign or Adobe Sign). Each one is its own quarter of work. You can squint at any one of those layers and tell yourself it's a week of work. They are not a week of work. § 04 ## [The three taxes nobody priced in](#the-three-taxes-nobody-priced-in) Once the architecture is standing, the work doesn't stop. Three ongoing costs come due, in the order most teams hit them. ### The engineering tax Building this is not a project. It's a commitment. Each layer above is months of engineering, not weeks. A first production version takes a small team somewhere between half a year and a year and a half, depending on how much of the integration surface you actually need. After that, you need at least one engineer permanently on it — for maintenance, prompt rot, model upgrades, eval drift, and the next integration the legal team will inevitably ask for. For most in-house legal teams, that team does not exist. It is not on the GC's hiring plan. And it's not a hire a GC can credibly justify on the leasing line item alone — the engineering org will ask why this isn't living in central platform. ### The eval and governance tax Anthropic ships model updates. The teams using Claude get the new model. When the model changes, the behavior shifts — sometimes in a way the team notices, often in a way they don't. The discipline for catching this is called evals. It is its own engineering practice. You need a curated set of golden inputs and expected outputs, a scoring rubric, and a regression run on every prompt change, every model upgrade, and ideally every week. Legal teams are not staffed to run an ML eval program. They have not hired a head of model quality. Without that practice, the tool will silently drift, and the team will not know it drifted until a clause goes missing from a signed lease. ### The accountability tax This is the one the buyer feels last and worst. When the model produces a draft with a missing co-tenancy clause, or a CPI escalation pegged to the wrong index, or an SNDA reference that points at a deleted exhibit — and a tenant signs it — the question is, \_who owns the bug?\_ With a vendor, the answer is on a contract somewhere. It runs through their SLAs, their indemnification language, their support team. There is a phone number to call. With a DIY build, the answer is your in-house IT team and the legal department that approved the rollout. The accountability lives entirely inside your organization. For some teams that's an acceptable trade. For most institutional landlords with billions of dollars of lease obligations in flight, it is not. § 05 ## [The probabilistic question, briefly](#the-probabilistic-question-briefly) There's a separate argument about why large language models are a poor fit for lease drafting in the first place — the architecture is probabilistic, and lease math is deterministic. Rent schedules, CAM reconciliations, percentage rent breakpoints, escalation formulas. None of them can be "probably right." I'm not going to re-litigate that here. The full version of the argument is in [LeasePilot vs. AI Lease Drafting Tools](/blog/leasepilot-vs-ai-lease-drafting-tools). What matters for this post is that \_because\_ of the probabilistic-vs-deterministic problem, the calculation layer in the previous section is not optional. It is the work you would have to build to make a Claude pipeline usable, and it is the work most DIY projects underestimate by an order of magnitude. § 06 ## [DIY on Claude, next to a vertical platform](#diy-on-claude-next-to-a-vertical-platform) Each row is a workstream you would have to staff. Read it as a one-page diligence summary, not a marketing chart. Workstream DIY on Claude Vertical lease-drafting platform Clause library Build and maintain in-house Encoded during onboarding State and jurisdictional rules Track and update yourselves Vendor-maintained Calculations Build a separate deterministic layer; integrate Already deterministic, built into assembly Evals Build a golden-set suite; run on every model or prompt change Vendor's regression burden Word-shape output Build a renderer Native Integrations (Yardi, MRI, Okta, DocuSign) One project each Already shipped Security and compliance Your team's lift Vendor-attested Accountability Internal Contractual Eight workstreams. Each one is real work. None of them are visible in the demo that started the project. § 07 ## [When DIY on Claude is the right call](#when-diy-on-claude-is-the-right-call) The point of this post is not that no legal team should build on Claude. There are situations where it's the right answer. - **You already have a platform engineering team with capacity.** Maybe you're an Am Law 50 firm with a serious legal-tech investment, or an institutional landlord whose parent company runs its own engineering org. The build tax is still real, but it's a tax you can afford. - **The artifacts are not 60-page leases.** Vendor NDAs, internal templates, employment letters, board memos. These have lower stakes, less arithmetic, no jurisdictional rule engine, no system-of-record connections. Build it. - **You're optimizing for research, not production drafting.** "What does our portfolio look like across renewal options?" — that's a one-shot question, not a tool the legal team needs to depend on for daily output. - **You're a tech-forward law firm willing to invest in proprietary tooling as a competitive moat.** A small number of firms will be glad they took the bet. The horizon is three years to payoff, and the bet is expensive. Lease drafting at scale, for an institutional landlord with state-specific provisions and ten-year financial obligations, is not on this list. That's the gap we built LeasePilot for. § 08 ## [The bottom line](#the-bottom-line) Claude is excellent software. Lease drafting is a system. The distance between those two sentences — and the platform team you would need to close it — is the actual cost of building this yourself. Most legal teams will spend a year discovering this. The two groups David spoke with were already months into their builds when they realized they weren't alone. Neither had shipped to production. Neither knew the other existed. If you're at month one, this post is for you. If you're at month nine, you already know. § Adjacent reading ## More from the ledger [§ 01MAR 27, 2026 Industry Insights ### LeasePilot vs. AI Lease Drafting Tools: Why Deterministic Beats Probabilistic for Legal Documents LeasePilot Team7 MIN READ Read →](/blog/leasepilot-vs-ai-lease-drafting-tools) [§ 02MAR 24, 2026 Industry Insights ### LeasePilot vs. CLM Platforms: Why Contract Lifecycle Management Wasn't Built for Leases LeasePilot Team7 MIN READ Read →](/blog/leasepilot-vs-clm-platforms-ironclad-agiloft) [§ 03MAR 20, 2026 Industry Insights ### LeasePilot vs. HotDocs and ContractExpress: Why Generic Document Automation Falls Short for CRE LeasePilot Team7 MIN READ Read →](/blog/leasepilot-vs-hotdocs-document-automation) § See it in practice ## Reading about it is one thing. Watching it happen is another. See LeasePilot draft a lease in your team’s own templates, with your clauses and your defaults. [Schedule a Demo](/demo)