Build vs adopt: the real cost of a PDF stack

SpecSpec: ISO 32000-2ISO 32000-2SpecSpec: ISO 19005-4ISO 19005-4SpecSpec: ETSI EN 319 142-1ETSI EN 319 142-1

At a glance

Building a PDF writer is deceptively easy to start and genuinely hard to finish. A weekend produces a file that opens. Production wants a document that signs, archives, stays accessible, and survives a security audit — for years, maintained by whoever is on call that week.

This page is the build-vs-adopt decision framed as economics: the recurring, mostly invisible cost of owning a PDF stack yourself, set against adopting an open-core engine. It is honest about both directions, including when rolling your own is the right call.

Why this matters

The cost that sinks a self-built PDF stack is almost never the first version. It is everything after. A PDF is a long-lived artifact: it gets signed, archived, read by assistive technology, and validated by someone who was not in the room. Each of those is a moving target with its own standard, and each one keeps moving after you ship.

So the question is not “can we build a PDF writer.” Almost any team can. The question is “can we afford to keep one correct.” That is a different budget, and it is the one a green-field prototype never shows you. The bill arrives later, as a signature a validator rejects, an archive a checker fails, an audit finding on accessibility, or a CVE in a parser nobody has touched in two years.

The short version

The honest costs of building your own, in rough order of how often they are underestimated:

• The standards treadmill. PDF 2.0 (SpecSpec: ISO 32000-2, §6ISO 32000-2 §6), PDF/A, PAdES, and PDF/UA are separate, evolving standards. Matching one is a project. Keeping pace with all four is a permanent staffing line.
• Fonts and text encoding. Subsetting, glyph mapping, ToUnicode, complex scripts, and bidirectional text are the part everyone underestimates and nobody finishes on the first try.
• Security CVEs. A PDF engine parses and emits a complex binary format. That surface attracts vulnerabilities, and owning the code means owning the patch cadence forever.
• Accessibility and tagging. PDF/UA tagging (SpecSpec: ISO 14289-1ISO 14289-1) is structural; bolting it on after the fact is far more expensive than building it in, and “we’ll do it later” usually means “we’ll do it under audit pressure.”
• Bus-factor. The person who understands your cross-reference table is one resignation away from being nobody.

Adopting an open-core engine moves those recurring costs off your team while leaving you the freedom to leave — because the output is a standard PDF and the core is Apache-2.0, not a proprietary container.

How NextPDF approaches it

The premise is simple: the parts of a PDF stack that cost the most to own are exactly the parts that benefit most from being shared, standards-grade, and tested once for everyone. NextPDF is built so those costs are amortised across every team that adopts it, instead of re-paid by each team that builds.

Walk the recurring lines a self-built stack carries, and where adoption changes the bill:

1. The standards treadmillPDF 2.0, PDF/A, PAdES, and PDF/UA evolve independently. Adopting an engine makes tracking them the maintainer's recurring obligation, not a line on your roadmap.
2. Fonts and encodingSubsetting, glyph mapping, ToUnicode, and complex scripts are solved once in a tested engine rather than rediscovered, edge case by edge case, in yours.
3. The CVE surfaceA binary-format parser and renderer attract vulnerabilities. A shared engine concentrates the patch effort; you update a dependency instead of auditing your own writer.
4. Accessibility taggingPDF/UA structure is built into the output path, not retrofitted under audit pressure — the most expensive time to add it.
5. Bus-factorAn Apache-2.0 core you can read, fork, and vendor replaces a single engineer who happened to understand the xref table.

The recurring cost lines of owning a PDF stack, and how adopting an open-core engine changes each: the standards treadmill becomes the maintainer's job rather than yours; font and encoding edge cases are solved once and tested; the parser and renderer CVE surface is patched centrally; accessibility tagging is built in rather than retrofitted; and bus-factor moves from one engineer to a maintained, Apache-2.0 codebase you can still read and fork.

The standards treadmill is the line teams forget to budget. PDF 2.0 is the version-of-record for the format (SpecSpec: ISO 32000-2, §6ISO 32000-2 §6), and it is only the base layer. Archival adds PDF/A-4 (SpecSpec: ISO 19005-4, §6ISO 19005-4 §6). Signing adds the PAdES baseline profiles (SpecSpec: ETSI EN 319 142-1, §6ETSI EN 319 142-1 §6). Accessibility adds PDF/UA (SpecSpec: ISO 14289-1ISO 14289-1). These are four separate standards, maintained by different bodies on different schedules, and your document may have to satisfy several at once. Implementing each is a real project. Keeping all of them current — as profiles revise and validators tighten — is not a project that ends. It is a recurring obligation, and on a self-built stack it is yours.

Fonts are where the iceberg is. “Embed a font” sounds like one task. In practice it is subsetting, glyph-to-character mapping, a correct ToUnicode map so the text is selectable and searchable, and then the long tail: complex scripts, ligatures, and bidirectional text. A team building its own writer typically gets Latin text working quickly and then spends quarters on the edge cases — the part that decides whether a screen reader, a search index, or a copy-paste actually works. NextPDF treats that as core engine work, done once and regression-tested, not as a problem each adopter rediscovers. The depth of it is the subject of fonts, the hard part.

Security is a cadence, not a milestone. A PDF engine reads and writes a complex binary format, which is precisely the kind of surface that produces vulnerabilities over time. Owning the code means owning the response: triage, patch, release, and notify — indefinitely. Adopting a maintained engine concentrates that effort in one place and turns your cost into a dependency update. It does not make the risk disappear; it makes the patch somebody’s standing job rather than an emergency you discover during an incident.

Accessibility is cheapest when it is built in. PDF/UA accessibility is about tagged structure — headings, reading order, alternate text — woven into the document as it is written (SpecSpec: ISO 14289-1, ScopeISO 14289-1 Scope). Retrofitting tags onto an untagged writer is far more expensive than emitting them from the start, and the retrofit usually happens at the worst time: when a procurement requirement or an accessibility complaint makes it urgent.

Human-factors note:Human-factors note

The line that almost never makes the build-vs-buy spreadsheet is maintainability — a named software-quality property covering how modular, analysable, and modifiable a system stays over its life (SpecSpec: ISO/IEC 25010:2023, §3.7ISO/IEC 25010:2023 §3.7). A self-built PDF stack is cheap on the day it ships and expensive on every day after, because the cost lives in the changes — the standards revision, the font edge case, the CVE patch — made by people who did not write the original. Adoption is, in part, a decision to pay that maintenance cost as a shared, predictable line instead of an unpredictable internal one.

Practical example

The economics are easiest to see at the call site. Adopting the standards-grade output is one public-registry dependency; the same short program that a team writes to evaluate the engine is the one that runs in production.

<?php

declare(strict_types=1);

// composer require nextpdf/core
//
// One dependency carries the standards work a self-built stack would
// otherwise own forever: PDF 2.0 structure, font subsetting and ToUnicode,
// and the tested output path. You update a version; you do not maintain a
// writer.

use NextPDF\Contracts\Orientation;
use NextPDF\Contracts\OutputDestination;
use NextPDF\Core\Document;
use NextPDF\ValueObjects\PageSize;

$document = Document::createStandalone();
$document->setTitle('Quarterly Report');

// Typed geometry and an enum orientation: intent is explicit, so a typo is a
// type error in development, not a malformed page discovered in production.
$document->addPage(PageSize::a4(), Orientation::Portrait);
$document->setFont('helvetica', 'B', 16);
$document->cell(0, 12, 'Quarterly Report', newLine: true);

// Standards-grade bytes, from the open core. The font embedding, the cross
// reference structure, and the PDF 2.0 conformance work are inside the engine,
// maintained by its authors, not carried on your roadmap.
$bytes = $document->output(dest: OutputDestination::String);

Nothing in that program is a stub you have to finish later. The work that a self-built stack would defer — and then pay for under pressure — is already inside the dependency, tested and maintained.

Common misconception

The frequent build-side argument is “our needs are simple, so a thin wrapper is cheaper than a dependency.” It is cheaper on day one, and that is the trap. The cost of a PDF stack is not the first document; it is the standards revision, the font that renders as boxes, the CVE in your parser, and the accessibility finding — none of which appear in the prototype. A thin wrapper is a fair plan right up until your needs stop being simple, which they reliably do the moment a document becomes a legal or archival artifact.

A second misconception is that adopting an open-core engine just trades in-house lock-in for vendor lock-in. It does not, and that is deliberate. The core is Apache-2.0 and the output is a standard PDF any conforming reader opens, so leaving costs you nothing you cannot do yourself — the licensing-led case is made in full on open core, no lock-in. The feature-led case for adopting at all lives on why teams choose NextPDF; this page is only the cost argument.

Limits and boundaries

Adopting is not always the cheaper answer, and pretending otherwise would be the same dishonesty this page argues against. Building your own is the right call in real cases:

• A genuinely trivial, one-off document — a fixed receipt, a single label — where a few lines of hand-written output will never grow standards obligations. Adding a dependency for that can cost more than it saves.
• A need NextPDF explicitly does not serve: pixel-faithful rendering of arbitrary modern web pages, OCR of scanned input, or heavy interactive editing of third-party files. Those are a different shape of problem, and forcing this engine into them is its own kind of build cost. The honest list is on when not to use NextPDF.

This page is also an argument, not a benchmark. It does not put a number on your total cost of ownership, because that number depends on your obligations, your volume, and your team — figures only you have. What it claims is structural: the recurring costs of a PDF stack are real, they are mostly invisible at the start, and a shared engine moves them off your roadmap.

One boundary deserves naming. Adopting moves the maintenance cost, not every cost. Higher-tier capabilities are a deliberate, paid dependency you take on knowingly, not a free part of the core.

Long-term-validation and HSM-backed signing — edition availability

Edition	Availability
Core	○Not in this edition — software signing at the baseline levels (B-B, B-T) is included.
Pro	○Available — long-term-validation levels and hardware-backed keys.
Enterprise	○Available — long-term-validation levels and hardware-backed keys.

The conformance verdict, finally, is never the engine’s to give. NextPDF can target PDF/A and PAdES, but whether a file conforms is decided by an independent validator, in every edition. Treat the engine as what gets you to “should pass,” and the checker as what says “does pass.”

Related docs

• Why teams choose NextPDF — the feature-led case for adoption; this page is its cost-side companion.
• Open core, no lock-in — the licensing-led case: why adopting does not trade one lock-in for another.
• When not to use NextPDF — the honest non-fit cases, including when building or delegating is the right call.
• The standards landscape — the PDF 2.0, PDF/A, PAdES, and PDF/UA map that explains why the treadmill exists.

Glossary

• Total cost of ownership (TCO) — the full lifetime cost of a system, not just its initial build: maintenance, standards tracking, security patching, and the staffing those require. The figure a green-field prototype hides.
• Standards treadmill — the recurring obligation to keep an implementation current as the standards it targets (PDF 2.0, PDF/A, PAdES, PDF/UA) revise on independent schedules.
• Bus-factor — the number of people whose sudden departure would leave a system unmaintainable. A self-built PDF writer often has a bus-factor of one.
• Open core — a model where a permissively licensed open-source core is surrounded by optional, paid add-ons. The foundation is yours to keep; the advanced capabilities are optional.
• PDF/UA — the accessibility profile for PDF (PDF/UA-1 under ISO 14289-1): tagged structure, reading order, and alternate text that make a document usable with assistive technology. Expanded on first use.
• PAdES — PDF Advanced Electronic Signatures, the ETSI profile family (EN 319 142-1) for signing PDFs. Its baseline levels are what a European validator expects to see.