Build vs Buy: Salesforce Document Generation

Someone on your team can build this. That is not in question, and it is exactly why the decision is hard. A Visualforce page, or an Apex callout to a rendering service, or an LWC that assembles HTML and posts it somewhere to come back as a PDF. The first document works in a week.

The decision is not whether you can build it. It is whether document generation is something your team should own for the next five years.

A note on scope. We sell one of the two options, so assume our thumb is on the scale. The cost model below is the one we would use ourselves, and the case for building is stated honestly because for some teams it is the correct answer.

The four questions that decide it

Answer these before pricing anything.

1. How many distinct document types will exist in three years? One is a build. Fifteen is a platform, and you have just decided to staff one.

2. Who needs to change a layout, and how often? If a business user wants a logo resized or a subtotal added, does that go through a developer and a release? A build almost always means yes. That is the recurring cost, and it is paid in the scarcest thing you have.

3. What happens when a document is wrong? Wrong invoice totals cost money and trust. A build gives you whatever validation you write, which under deadline is usually none. Silent blanks are the default failure mode of every merge-shaped system nobody hardened.

4. Is this a differentiator? Does a customer choose you because of how your PDFs are produced? If not, it is infrastructure. Own the things customers choose you for.

What building actually costs

The estimate covers v1. The bill is for everything after it.

Phase	What is actually involved
v1	The page or service, the layout, the data query. Feels fast, and genuinely is
The second document	Either you copy v1, and now maintain two, or you extract an abstraction and start building a template engine
Rendering	Visualforce's engine understands roughly CSS 2.1 and HTML 4; an external renderer means data leaving the org, plus auth, retries, and timeouts
Page mechanics	Headers, footers, and page breaks. Content overlapping the header on page two is a rite of passage, and padding fixes break on the next content change
Structure	Grouping, subtotals, nested collections, conditional sections. This is where in-house builds stall, because it is genuinely hard
Validation	Nobody builds this in v1. It is what stops a blank total reaching a customer
Change requests	Perpetual, and every one is developer time
Bus factor	One person understands it, and they will eventually leave

Two costs get missed almost every time.

The abstraction tax. The second and third documents are the point where you stop building a document and start building a document system: a template model, a data-binding layer, conditional rendering. That is a product, and it now competes for roadmap against things customers actually asked for.

Maintenance is forever. Build cost is one-time and visible. Maintenance is recurring and invisible until it is a quarter of someone's capacity. The same dynamic shows up in bought tools as docgen debt; building does not exempt you from it, it just moves who pays.

When building is the right call

Real cases, not straw men:

One document, forever. A single internal PDF that will not change. Build it and buy nothing.
The output is genuinely unusual. A regulator-mandated fixed-position form, or a machine-readable format with an odd specification that no product targets.
You already have a working platform. Some orgs built a good internal engine years ago and it still works. Do not rewrite a working system in order to buy something.
Extreme volume with unusual economics. At sufficient scale, per-document pricing can dominate engineering cost. Model it rather than assuming it in either direction.

Note that "the data cannot leave our org" is not on this list, because it no longer forces a build. It rules out middleware-based tools, not native ones.

One thing worth doing before committing engineering weeks: the cheapest way to price a build is to see how far the bought option gets in an afternoon. ZeroExport's free tier is three active templates, free forever with no credit card, so you can put your hardest document through it and find out whether the part you were dreading is already solved. If it is not, you have a sharper build spec than you had this morning.

When buying is the right call

Multiple document types, and the number is rising.
Business users should own layout. Moving layout changes off the developer queue is usually the entire return.
Documents are structurally complex — grouped subtotals, nested products, conditional sections. This is the expensive part of building and the part that is already solved.
Correctness matters. Validation before a document ships is unglamorous, always deprioritized in a build, and exactly what prevents the expensive failure.
You want a bus factor above one.

The middle path nobody mentions

You do not have to choose globally. Buy for the document types that change often and face customers, and keep the one unusual internal thing you already built. Most healthy orgs end up here. A build is not a religion, and neither is a purchase.

The same applies in time as well as in scope. Nobody has to migrate everything to find out whether buying was right — move one document, run it alongside what you have, and let that decide the second one. The phased migration playbook is written for teams leaving a vendor, but the sequencing works identically when what you are leaving is your own code.

If what you have today is a Visualforce PDF page rather than a greenfield decision, the more specific version of this question is whether to keep or replace it.

FAQ

Is building document generation cheaper than buying?

For the first document, usually yes. The crossover typically arrives around the third document type or the first year of change requests, and it is driven by how often documents change rather than by how many exist.

We have spare developer capacity. Does that change the answer?

It changes the price, not the question. Capacity spent maintaining document infrastructure is capacity not spent on the product your customers actually buy.

Can we use AI to generate the templates instead?

AI is genuinely useful for a first draft, and it does not resolve build versus buy because it speeds up authoring in both. The caveat holds either way: a model will confidently produce a template whose totals look right, so pair it with validation that proves the field references resolve before anything goes live.

Does buying mean our document data leaves Salesforce?

It depends on the tool. Middleware-based tools process documents outside the org, which is what security reviews flag. ZeroExport is a managed package that runs entirely inside Salesforce, so this constraint does not force you into building.

We have already built it. Should we replace it?

Only if maintenance now exceeds the cost of a license. If it works and nobody is complaining, it works. Revisit when the third change request in a quarter lands, or when the person who wrote it moves on.