Build vs buy
Building contract generation yourself.
Build contract generation in-house if contracts are your product, if your agreements are unusual enough that no general model fits, or if a hard requirement rules out an external service. Buy it if contracts are a feature of a product that is about something else. The deciding question is not whether your team can build it. Most can. It is whether the year it takes is the best year they could spend.
What follows is the work itself, in the order teams meet it, with the naive approach and the thing that breaks it. We have deliberately not put a dollar figure on it: we don’t have defensible data across enough integrations to publish one, and an invented total would be the least trustworthy thing on this page. Apply your own rates.
The work
In the order it arrives, not the order it’s planned.
Eight problems, and the shape of each.
Document fidelity
The plan: Extract the text, render a new PDF from a template.
What breaks: The output is not the customer's contract any more. Clause numbering shifts, tables lose their formatting, the letterhead is gone, and the business whose lawyer approved that document will not send it. Filling the original DOCX in place is a different and much harder problem than rendering a new document.
The field model
The plan: Merge fields. Substitute values into placeholders.
What breaks: The first payment schedule arrives and needs a variable number of table rows. Then a deposit that is a third of the fee. Then a clause that applies only when there is a security deposit. Substitution expresses none of it, and by the time you know that, templates exist in production using the old model.
Getting templates set up at all
The plan: Let businesses mark up their own contracts with placeholders.
What breaks: They won't. This is where onboarding dies in practice: a business user will not reliably annotate a twenty-page legal document, and one annotated wrongly produces wrong contracts without telling anyone. Detecting the structure automatically is the only version that onboards, and that means a review UI that highlights proposals in the document itself.
Arithmetic you can defend
The plan: Compute totals in application code with floats.
What breaks: Money in floating point is wrong eventually, and 'eventually' means in an executed agreement. You need decimal-safe evaluation, a formula representation that is data rather than code, and a rule that the same inputs always produce the same document, which also rules out asking a language model to do the maths.
Validation, and what to do when it fails
The plan: Send it; the user will notice mistakes.
What breaks: A contract sent with the wrong number is a commercial incident, not a bug report. You need a gate that catches empty required fields, arithmetic that contradicts itself, and cross-field contradictions, plus a state machine where failure produces a draft for review rather than a send. Nobody scopes this, and everybody needs it.
Signing, and everything after it
The plan: Call the e-signature API.
What breaks: The API call is a day. Ordering signers, placing signature fields at the right coordinates, handling status webhooks idempotently, retrying failed deliveries with backoff, reconciling a provider that went down mid-batch, and surfacing all of it to your users is the rest of the quarter.
Versioning and reproducibility
The plan: Templates are rows; edit them in place.
What breaks: A contract signed under last year's template must still be reproducible, exactly, years later. That means versioned templates, contracts pinned to the version they used, and the resolved values stored alongside. Retrofitting this after the first year of contracts exists is a migration nobody enjoys.
The maintenance nobody counted
The plan: It's done once it ships.
What breaks: Word documents produced by a decade of different software, tenancy isolation on every query, an audit trail that never logs contract content, a signature provider that changes its API, and a support surface where every ticket is about someone's legal agreement.
Build anyway
Cases where we are the wrong answer.
When you should build it.
A comparison that concludes “buy” in every case is marketing, not analysis. These are the situations where building is genuinely correct.
- Contract generation is your product. If this is the thing customers buy from you, it cannot be someone else’s infrastructure.
- Self-hosting is a hard requirement. Conovo is not self-hostable today. If your customers’ contracts cannot leave your infrastructure, that ends the conversation honestly rather than after a procurement cycle.
- Your documents are genuinely exotic. Agreements that are primarily complex tables, filings against a regulator’s own format, or documents assembled from a clause library you already maintain and vet.
- You have already built most of it. If rendering, the field model and validation exist and work, the remaining gap may not justify a migration.
Comparison
Where each option genuinely sits.
Against the alternatives, fairly.
| Option | Best when | What it leaves you |
|---|---|---|
| Build in-house | Contracts are the product, or self-hosting is mandatory | Total control, and permanent ownership of the whole surface |
| E-signature API alone | Your users bring finished documents | Signatures solved; document assembly still done by a human |
| Generic document/PDF API | You already have the values and just need rendering | Rendering solved; field model, validation and signing still yours |
| CLM platform | Your legal team is the user and logs in directly | A product for them, not something embeddable in yours |
| Conovo | Contracts are a feature of a platform about something else | The pipeline, embedded; you keep the brand and the data model |
Questions
The ones that decide it.
Common questions.
Should we build contract generation in-house?
Build it if contract generation is your product, if your contracts are so unusual that no general model fits them, or if a hard requirement makes an external service impossible: self-hosting, a specific jurisdiction's signing regime, an existing document pipeline you already maintain. Buy it if contracts are a feature of a product that is about something else, which is the common case for vertical SaaS. The deciding question is not whether your team can build it; it is whether the year it takes is the best year they could spend.
What is genuinely hard about generating a contract?
Three things, in increasing order. Filling the original document in place so formatting, clause numbering and tables survive exactly, rather than rendering a new document that merely reads correctly. A field model expressive enough for arithmetic between fields, tables with a variable number of rows, and clauses that only sometimes apply. And a validation gate strong enough that a wrong number becomes a draft for review rather than an executed agreement.
Can't we just use an LLM to fill the contract?
Not for the values. A model is genuinely good at reading a contract once and proposing which parts vary. That is setup, and a human confirms it. It is the wrong tool for producing the values that land in an executed agreement, because it cannot guarantee that the same inputs produce the same document, and it cannot be trusted with money arithmetic. The defensible architecture uses AI at setup and deterministic code on the send path.
What if we already have a document generation service?
Then you have solved the rendering step, which is real progress, and the remaining work is the field model, the binding layer to your own schema, validation, signing orchestration, versioning and reproducibility. Whether that is worth buying depends on how much of it you have already built rather than on the rendering you have.
How do we evaluate this without committing?
Set up an account, upload a real contract of the kind your users send, and see what gets detected and what does not. The sandbox does real extraction against real documents and generates real files without a card. That is a better signal than any estimate in this page, including ours.
Next
Test it against a real contract.
Upload one your users actually send and see what gets detected. That is a better signal than any estimate here. Then read the generation API and what the integration looks like.