Should you rebuild your document automation with AI?
I sell enterprise document automation software.
In this article, I’m going to tell you when you shouldn’t buy it.
That’s not a rhetorical pose. We have always told prospects that if their templates are simple and there aren’t many of them, ActiveDocs is the wrong product for them. What has changed is where we send them next. For years the answer was a cheaper, more basic product. Now the answer is more likely to be: go and build it.
Same conversation, but these days, a different destination. That shift is the clearest signal I have that something real is happening.
One caveat before I go further. I have not knowingly sat inside a build-versus-buy decision where AI was the deciding factor. Nobody has two years of evidence about how AI-built internal tools age, because they haven’t existed for two years. What follows is reasoning from what I can see from where I sit.
What got cheap, and what didn’t
Building got cheap. Someone who is not a developer can now produce a working document generation system in weeks. That is a genuine change and there is no point pretending otherwise.
Working out what to build got slightly cheaper. AI is good at interrogating existing artefacts, and a template portfolio is a large pile of artefacts.
Proving it works got no cheaper at all. Neither did owning it when it doesn’t work.
This is the gap that build business cases keep missing. The cost of a build is not the cost of building. It’s revalidation. Legal sign-off. Regulatory re-approval where that applies. Parallel running while you convince yourself the new thing matches the old thing. Retraining the people who author templates. And then the standing cost of getting a call when it breaks.
Put another way: conversion cost is trending towards zero, and migration cost isn’t. AI will port your artefacts – whether they’re already automated or still sitting in Word – and discharge none of your assurance burden. If your business case has a number for the build and no number for the proving, it isn’t a business case yet.
Two layers, and only one of them is visible
Document automation has two distinct layers, and the rebuild question looks completely different depending on which one you’re looking at.
The template layer is yours. The conditional logic, the clause selection rules, the data mappings – this is your intellectual property, accumulated over years, and it is almost entirely load-bearing. It’s there because it produces the correct document. I don’t think much of it is dead weight, and I want to be clear that this layer is now genuinely cheap to move. If someone tells you AI can’t port your document assembly logic, they’re defending a position that’s already lost. Porting logic is a translation problem, and translation is what these tools are good at.
The product layer is the vendor’s. Bulk update across several hundred templates. Impact analysis before you change a clause that appears in eighty of them. Version control and rollback. Approval workflow. Separation of roles between the person who drafts, the person who approves, and the person who publishes. Test harnesses. Audit trails that survive contact with an auditor.
None of that appears in a requirements document, because nobody writes down the things they don’t know they rely on. Which produces the central risk of a build: it ports what you can see and silently drops what you can’t.
The templates come across fine. The reason managing them was tractable does not.
The mismatch nobody prices
In my experience, roughly 90% of that product layer is durable – the features we built five years ago still earn their keep. The 10% that decays is mostly integration surface, and it decays because other people’s software decays. We retired parts of our SharePoint integration because Microsoft stopped supporting what it connected to. That’s not a failure of design; it’s the weather.
So the fastest-depreciating part of the product is integrations, and integrations are exactly what buyers scrutinise hardest in an RFP. Meanwhile the durable 90% is close to invisible in a procurement process, because it consists of things you only notice in year three.
That mismatch cuts both ways. It’s why buyers underestimate what a build costs them. It’s also why a vendor doing patient work on the durable layer can look stagnant next to one shipping connectors.
Nothing new, and no more excuses
I had an uncomfortable moment while working through this. I wrote down what separates a document automation solution worth paying for from one that isn’t:
- Quick response to client requirements
- Reliability
- The services around it – deployment, support, the unglamorous parts
- The ability to demonstrate return quickly
Then I looked at the list and realized none of it is new. That has always been the list.
What changed is tolerance. When building software was hard, being able to build it at all was a form of differentiation, and slowness had cover. Capability was scarce, so capability was the product. Now capability is abundant, and the scarce things are judgement, reliability, and someone who will be accountable when the output is wrong.
The return-on-investment conversation moved with it. Your alternative is no longer “do nothing.” It’s “someone in operations builds something in a fortnight.” Every business case a vendor puts in front of you is now measured against that baseline, whether or not the vendor has noticed.
The test
So: should you build it yourself?
Build it yourself if all three of these hold.
Under about 20 pages of automated content. It doesn’t matter whether that’s twenty one-page documents or one twenty-page document. Think proposals, contracts, statements of work: whatever carries the logic. Static content doesn’t count – but static content that gets swapped out based on business rules absolutely does count, because that’s automation wearing a disguise.
Simple conditional logic. Volume is the wrong measure on its own. Two pages carrying forty interacting rules, drawing from three data sources, is a harder problem than twenty near-static pages with three swap conditions. Rule density and interaction predict pain better than page count.
A low rate of change. A hundred pages frozen for five years is a lighter burden than twenty pages a regulator touches every quarter. The cost of automated documents doesn’t live in the build; it lives in the years of revalidation afterwards.
Fail any one of the three and you should buy.
Why 20? It’s not derived from theory – it’s roughly where, across our customer base, we’ve watched the pain change character. Below it, the burden is the automation itself: rules to write, mappings to maintain. Above it, a second cost takes over and grows faster than the page count – the need for the product layer. Data connections that behave the same way everywhere. Content reused across templates instead of copied between them. Knowing what a clause change touches before you make it. Approval before publication. None of that matters at five pages. All of it matters at fifty. Twenty is about where an in-house tool stops being hard work and starts being a fire to fight.
And watch for the trap, because it’s how most in-house tools are born and how most of them die: the requirement that starts at fifteen pages and simple rules, and is sixty pages with an approval workflow bolted on within two years. The build decision was correct on the day it was made and wrong eighteen months later, by which point nobody wants to reopen it. The irony is that the better the in-house tool, the faster it dies – quality attracts scope, and scope is what kills it.
Below that line, though, I’ll say plainly what the rest of this industry is reluctant to: build it. It now genuinely means AI-built, in weeks, by someone who isn’t a developer. That’s real, and it’s why the cheap end of this market is disappearing rather than getting cheaper.
If you buy, stop accepting these answers
Above the line, buying is the right call – but the abundance of capability should change what you tolerate from a vendor.
Start here: “we can’t build that” is almost never true. Everything is possible in code. What you’re being told is that it’s a roadmap decision, and there are two kinds of roadmap decision.
Too resource-demanding. This is now an admission rather than a reason. If AI is compressing development effort across the industry – and it is – then it’s compressing your vendor’s. A feature with broad applicability, which is not specific to you, should reach a release in weeks or a few months. A multi-year backlog for things every client would use is a statement about the vendor, not the difficulty.
Doesn’t fit the product direction. This one is often legitimate, and it’s worth explaining. A vendor who builds every client-specific request becomes a consultancy with a product attached. The coherence gets eaten first, then the durable 90% you’re actually paying for. Saying no to bespoke work is what protects the thing you’re buying. We tell clients this directly, and I’d rather be told it than managed around it.
Which gives you the diagnostic to apply when you hit a wall:
Is my request specific to me, or does it have broader applicability?
If it’s broadly applicable and still refused, that tells you something about the vendor’s future rather than about your requirement. If it’s specific to you and refused, the refusal is probably correct – and the answer is to build that capability around the product, not to rebuild the product.
The rest of the list follows from the same logic. Integration points, with your CRM, your document management system, SharePoint, whatever holds your data, should be the default in any document automation platform now; not having them is hard to justify when the work to build them has collapsed. Manual steps in the product should be designed out rather than documented. And a release cycle measured in years is no longer something to apologise for – it’s something to lose deals over.
Before you commit
If you are going to build, treat what follows as risk analysis rather than received wisdom.
Who maintains it once the person who built it changes role? What’s the test suite, who runs it, and what happens when it fails? What’s the plan for the week a regulator changes a mandatory disclosure that appears in every document you produce? Who is on call?
And then the one that tends to end the conversation:
List every action your team took in the document automation product last quarter that wasn’t authoring or generating a document.
Bulk updates. Impact checks before a clause change. Approvals. A version rollback after someone published the wrong thing. Access changes when a team member left. An audit request. A migration of templates between environments.
That list is the product layer. It’s what a rebuild doesn’t get, and it’s the part that never made it into anyone’s requirements document. Most people are surprised by how long it is.
ActiveDocs builds document automation software inside Microsoft Word: template design, conditional logic, approval workflow, and audit trails, for banks, insurers, government agencies, and healthcare organisations running contract automation, proposal automation, and other compliance-critical document generation at volume. If you want a second opinion on your own build-versus-buy numbers, get in touch.
Martin Srubar is Senior Technology Evangelist at ActiveDocs. He works with prospects and customers on where document automation best fits their architecture, and feeds what he hears back into product direction.