Build vs. buy guide
AI coding agents made the first draft of a document feature genuinely fast. They didn’t change who owns it eighteen months later. This guide separates what actually got cheaper from what didn’t — with the criteria, the cost model, and the bake-off plan to make the call on evidence instead of instinct.
Why
The case for buying used to be developer-months. AI agents cheapened exactly that resource — so the honest math moved to maintenance, security, and compliance.
What
A decision framework for document features specifically: what to evaluate, what to measure on both paths, and when building is genuinely the better call.
Who it’s for
Engineering leaders sizing maintenance load, architects who already have an agent-built prototype, and product leaders weighing liability against velocity.
01
“Build vs. buy” is really a choice between five things, and most teams are debating two of them without naming which.
Write the document layer yourself, from the format spec up. Rare today outside companies whose product is document intelligence — the PDF specification alone runs past a thousand pages before extensions.
Stitch together pdf.js, PDFBox, Tesseract, Ghostscript, and friends. This is what most “build” decisions actually mean, and what a coding agent will reach for by default.
License a maintained engine with the edge cases, security response, and compliance conformance already handled. Not one SKU — a ladder of hosting and control tradeoffs.
In practice this is the open-source path with the assembly time compressed. The agent writes the glue; the libraries underneath, and their licenses and CVEs, are unchanged.
Buy the layer where being wrong is expensive — redaction, signing, conformance, extraction — and build the parts that are genuinely your product. Most durable answer for most teams.
02
The visible cost of a first draft fell. The invisible cost of owning it didn’t, and by several measures got worse.
An agent will wire up a viewer, a redaction script, or an OCR pipeline in an afternoon. This is real, and disputing it wastes everyone’s time.
Glue code between two well-specified interfaces is where agents are strongest. Stripe’s own benchmark scored Claude Opus 4.5 at 92 percent on full-stack integration tasks.
A team that stands up a document viewer in two weeks instead of two months has genuinely given up less core-product focus. The 2025 version of this argument no longer holds.
GitClear’s analysis of 211 million changed lines found refactoring fell from 25 percent to under 10 percent between 2021 and 2024, while duplicated code rose from 8.3 to 12.3 percent. More places for one defect to hide.
Google’s 2024 DORA report found AI adoption raises individual flow while measurably decreasing delivery stability and throughput — larger, less reviewable change sets.
CodeRabbit’s analysis of 470 real pull requests found AI-authored code averaged 10.83 flagged issues against 6.45 for human code, with logic and correctness defects up 75 percent.
Veracode tested 100+ LLMs across 80 tasks and found AI-introduced vulnerabilities in 45 percent of cases. File parsing has a two-decade CVE history that predates AI entirely.
PDF/UA tagging, PDF/A archival validity, and PAdES long-term signature validation are binary and validator-checkable. A model that is usually right is a different product from a pass.
Nothing about faster assembly changes who is on call for a CVE, who re-validates tagging after an upgrade, or who answers for a redaction that silently failed.
METR ran a randomized controlled trial with 16 experienced developers across 246 real issues in codebases they already knew. Developers with AI access were 19 percent slower — while estimating afterward that AI had made them 20 percent faster. METR itself flags that result as dated, and its February 2026 follow-up retracted confidence in measuring the effect at all, because too many developers now refuse to work without AI to recruit a clean control group. The durable finding isn’t the minus 19 percent — it is the gap between measured and perceived. When a team reports being two to three times faster, treat it as an honestly held belief that the best available research says runs ahead of reality, especially on long-horizon, hard-to-verify work.
Developers are not naive about this. Stack Overflow’s 2025 survey found 46 percent distrust the accuracy of AI output, up from 31 percent the year before, with 66 percent citing “almost right, but not quite” as a recurring problem and 45 percent saying debugging AI-generated code takes longer than debugging their own. The most experienced developers in the sample were the most skeptical.
03
Score your requirement against these before comparing costs. Most of them push the answer harder than price does.
Scope permanence
Will this genuinely stay narrow, or is “just viewing” the entry point? The single strongest predictor of whether a build works out. Be honest about the roadmap, not the ticket.
Cost of being wrong
A misrendered thumbnail is a bug. A redaction that didn’t remove the data is a disclosure incident. Grade each document operation by what a single silent failure costs you, not by how often it happens.
The accessibility, archival, and digital-signature standards (PDF/UA, PDF/A, PAdES) either pass a validator or they don’t — there’s no partial credit. The hidden structure a screen reader needs is present or it isn’t. This is the layer where “usually correct” has no value, and where the regulatory calendar is tightening rather than easing.
Adversarial input resilience
If users upload files, the code is reading bytes an attacker chose. A tiny file that expands to fill all available memory, an Office document that tricks the reader into fetching files off your server, an archive that writes outside the folder it was extracted into, a PDF with a deliberately corrupted index — these are a well-known category of attack with a published OWASP checklist, not exotic edge cases.
Maintenance ownership
Name the person who will understand this code in eighteen months well enough to change it safely. If an agent wrote the first draft, the old assumption that the author holds the mental model no longer applies.
Where documents are allowed to go
Requirements like running with no internet connection at all, sending no usage data back to a vendor, or keeping documents inside a specific country tend to surface late and eliminate options. Decide early whether documents may leave your network — it constrains both paths, not just the buy one.
Extraction structure
If documents feed agents or RAG, flat text is a downgrade you can’t undo at inference. Structure lost at extraction — headings, table cells, reading order — is gone. Several popular OSS parsers score zero on table structure recovery.
Platform spread
A build multiplies per platform. Web, iOS, Android, and server-side each need their own engine, their own annotation data model, and their own security response — and they have to render the same file identically.
Audit trail and provenance
Can you reconstruct how a given output was produced, months later, for a regulator or opposing counsel? “An agent did it” is not a chain of custody. Confidence scores, citations, and replayable runs are.
Agent readiness of the alternative
If you buy, your agent still does the integration. Machine-readable docs, typed SDKs, and a callable tool layer decide whether it generates working code or plausible fiction you debug by hand.
Three-year cost, not year one
Build costs front-load visibly and compound invisibly. Compare cumulative cost over three years against your own licensing options at ten times current volume.
04
No single open-source library covers the document lifecycle. “Just use pdf.js and PDFBox” already means four or more independently versioned projects, with different licenses and different maintainers, that you now integrate and own.
Browser rendering
Mature, actively released, and the engine behind Firefox and Chrome’s built-in previews. Genuinely good at what it was built for.
Can’t create or verify certificate-based digital signatures — the legally binding kind, as opposed to a drawn image of a signature. Limited screen-reader support relative to the PDF/UA accessibility standard. Scores 0.000 on table-structure recovery in public benchmarks — fine for viewing, a problem for AI pipelines.
Java read/write toolkit
Foundation-governed, 11,000+ commits, a PDF Association partner project, and one of the few OSS options with real digital signature support.
Adding a second signature to an already-signed document has historically stripped out the form data and silently invalidated the first signature. Checking a signature gets slow on files past a few megabytes. Interactive forms that change as they’re filled in are effectively unsupported.
Rendering, toolkit, interpreter
Technically excellent and standards-correct. MuPDF in particular is among the fastest engines available.
All three are AGPL with a single commercial licensing agent. Linking them into a closed-source product — or serving them over a network — obligates full source disclosure or a paid license. “Free” is doing a lot of work here.
Python read/write
Pure Python, pip-installable, well-documented, and the default an agent will suggest for Python.
Seven-plus publicly disclosed vulnerabilities in roughly twelve months, all triggered by feeding it a broken or hostile file — the library hangs forever, or eats all available memory until the process dies. Individually minor, but a steady pattern rather than a one-off.
OCR
98–99 percent character accuracy on clean, printed, Latin-script text. Deservedly the default OCR recommendation.
Roughly 90–95 percent on scanned PDFs, 70–85 percent on complex layouts, and 50–80 percent on handwriting. No native document-structure or reading-order understanding, which matters for anything downstream of extraction.
Conversion
LibreOffice converts Office formats with genuinely high fidelity and is actively maintained.
wkhtmltopdf was archived in January 2023 and carries an unpatched critical SSRF (CVE-2022-35583, CVSS 9.8) — any agent still recommending it is recommending abandonware. LibreOffice was architected as a desktop app and is not concurrency-safe without a process-pool layer you build.
Rendering engine
The engine inside Chrome and Edge, hardened by exposure to adversarial input at browser scale. Excellent standards fidelity.
Rendering only — no editing, forms, annotations, or signatures. No official standalone build pipeline, so integrating it outside Chromium means Chromium’s own toolchain and platform-specific workarounds.
Note also that this table is a web and server story. On iOS and Android the options thin out sharply: pdf.js is browser-only, PDFium has no official standalone build pipeline and needs platform-specific workarounds to compile, and Artifex sells separate paid “App Kit” SDKs for MuPDF precisely because the raw library requires real native build work on both platforms. A team shipping web and mobile isn’t integrating one stack — it’s integrating and maintaining a different one per platform, then reconciling rendering and annotation data models between them.
None of this makes open source a bad choice — these are good projects, and several are excellent at the one job they were built for. The claim worth holding is narrower and more defensible: they are incomplete for the full document lifecycle, and the integration surface between them is yours. For a deeper look at one of them, see the Nutrient vs. PDF.js comparison.
05
What teams assume
What actually happens
A working prototype and a production-safe implementation are different achievements. The gap between them is disproportionately made of the edge cases and security patterns that research consistently shows AI-generated code handles worst — in a domain built on parsing untrusted input from twenty years of non-conforming producers.
Someone still has to understand it. Qodo’s survey of 609 developers found 65 percent say AI tools miss relevant organizational context during refactoring and review. Code that ships clean but that nobody deeply understands is a maintenance liability with a delayed fuse.
MuPDF, Ghostscript, and iText are AGPL with a single commercial licensing agent each. Using them in a closed-source or SaaS product means disclosing your entire application’s source or buying a commercial license. The decision isn’t free versus paid — it’s which vendor, on which terms.
It isn’t, and the failure recurs at the highest levels. Manafort’s 2019 filing, Meta’s own legal team in the 2025 FTC antitrust trial, and the December 2025 Epstein files release all shipped black rectangles over recoverable text. Meta made the identical mistake a small litigant made six years earlier, with unlimited engineering resources.
PDF/UA tagging, PDF/A conformance, and PAdES long-term validation are architectural, not cosmetic. More than 5,000 digital accessibility lawsuits were filed in the US by the end of 2025, the ADA Title II deadline for public entities landed on April 24, 2026, and the EU Accessibility Act has had enforcement powers since September 2025.
Control is about owning outcomes. An agent-assembled stack doesn’t remove the vendor — it replaces one document SDK vendor with an unaudited set of open-source dependencies whose maintainer you now are, on a codebase whose mental model lives with whoever last prompted it.
06
Prototypes get tested on well-behaved documents. Production gets scanned forms from a printer nobody has heard of. Size the build against your worst file, not your best.
Ask who patches pypdf or Ghostscript the week a vulnerability drops, and what the SLA is. If the answer is “whoever’s free,” that’s the real cost line.
Viewing becomes annotation, then forms, then signatures, then redaction. Every document feature in this category has followed that path. Plan for the ceiling, not the entry point.
A build estimate that covers initial development but not maintenance, security patching, compliance validation, and review overhead is measuring the cheapest phase and calling it the total.
AGPL obligations in MuPDF, Ghostscript, and iText surface during legal review, usually after the architecture is committed. That is an expensive time to discover them.
Coding agents suggest dependency versions from training-data frequency, not live CVE lookups, and hallucinate plausible package names at a measured 5–22 percent rate depending on model. Verify what actually got installed.
07
Agents shrink the number you see in a demo and grow the one that shows up on a support queue, a security audit, or a compliance review eighteen months later.
Directional, not audited. Build your own version with your own salary and volume assumptions — the point is which rows move and which don’t.
| Cost category | Direction under AI | Why |
|---|---|---|
| Initial development | Compressed, meaningfully | First-draft and glue-code work is where agents are
strongest. This is the row that broke the 2025 argument, and
it broke for real. |
| Cross-platform integration | Compressed, less | Per-platform engine differences, native build systems, and
annotation data models stay largely manual. |
| Ongoing maintenance | Flat to worse | Duplicated code rose while refactoring fell across
enterprise codebases. More places for a single defect to
live means more per-fix cost, not less. |
| Code review and QA | Worse | More code shipped per hour is more code to review per hour
— against a measured 75 percent increase in logic and
correctness defects. |
| Security patching | Worse | Unchanged CVE cadence in the underlying libraries, now
against code the team understands less well. Agents also
suggest dependency versions by training-data frequency, not
live CVE lookups. |
| Compliance conformance | Unchanged | Accessibility and archival conformance is checked by a
validator. No amount of generation speed changes whether a
file passes. |
| Opportunity cost | Flat | Specialist judgment about document edge cases doesn’t
compress just because drafting did. Someone still has to
build and hold it. |
An independent February 2026 study prompted Claude Code 2,430 times across 20 unrelated tool categories, with no vendor names in any prompt, and recorded what it actually reached for. Custom code was the primary choice in 12 of 20 categories. Asked to add authentication, it wrote a bespoke implementation in 48 percent of cases across all languages — the single largest share of any option, and the exact “roll your own auth” pattern the industry spent a decade learning to avoid. (In the Python-specific slice it was 100 percent, which is worth knowing and worth quoting only with that qualifier attached.)
No equivalent study exists for document processing specifically, so read this as directional rather than proven for this domain. But there is no principled reason to expect document handling to be the exception to a build bias that consistent across 20 unrelated categories — which means the recommendation your agent gives you is not, by itself, evidence about which path is right.
08
We sell an SDK, so treat this chapter with appropriate suspicion — and then check it against your own situation. These are real signals, not a setup for a rebuttal.
01
Slack added inline PDF viewing in 2016 on pdf.js, scoped to display and text selection for small files — small enough to be a new engineer’s onboarding project. Years later it still had no annotations, forms, or signing, because that was the plan. A narrow build works indefinitely if the team accepts a hard, permanent ceiling.
02
Dropbox bought commercial OCR first to validate demand, then replaced it in-house once demand was proven — an eight-month program with a custom labeling platform, a from-scratch neural architecture, and millions of synthetic training words. That is the bar. If you have that team and that runway, build.
03
If a six-figure annual license is a meaningful fraction of runway and the requirements will change substantially within two quarters, the cheapest thing that unblocks the next milestone is a legitimate, capital-efficient choice — even knowing it may need replacing.
04
If what you need is self-serve, metered access with no sales call, that’s a packaging question, not an architecture one. Start on a usage-priced API and step up only when isolation or volume requires it.
In every documented document-processing build that worked, the team started from a mature third-party engine, not a blank file. Dropbox’s QuickPDF — which halved 75th-percentile time to interactive — was a custom C++ binary wrapped around a modified PDFium, arrived at only after two earlier approaches were outgrown. LinkedIn Learning’s accessible viewer was a heavily modified fork of pdf.js, because pdf.js doesn’t carry tagged markup through to the DOM; it took roughly 50 people across a dozen teams more than six months, and required engineers to work directly from the PDF specification.
None of those three conditions — sustained senior investment, an honestly narrow scope, and a mature engine underneath — is changed by a coding agent typing faster. If your plan is missing one of them, the plan is the problem, not the tooling.
09
Run both paths against the same corpus, in the same time box, and measure the things that only show up later.
01
A thousand real files, weighted toward the ugly ones — bad scans, rotated pages, Chinese or Japanese text with only part of the font embedded, generated by whatever produced your actual production traffic. Both paths get the same set.
02
Same engineers, same agent, same week. If the build path gets a month and the trial gets an afternoon, you’ve measured effort allocation, not capability.
03
Run the output through veraPDF — the free, industry-standard conformance checker — yourself. Don’t accept a conversion “success” rate from either path — vendors report 99 percent while actual conformance ranges from under 1 percent to 97 percent on the same files.
04
Inject a realistic edge case a week after the build is “done” — a font that renders one character off, a form field that won’t flatten — and time the fix. That number, not the build time, is what you pay for three years.
05
The developer who prompted the build is the worst judge of whether it’s production-safe — that’s the perception gap in chapter 02, applied to your own team. Get a second engineer to try to break it.
| Metric | What to measure | Why it matters |
|---|---|---|
| Critical failures at volume | 1,000+ files in one batch: count crashes, hangs, and
unrecoverable errors | Zero is the baseline. One crash per thousand is a daily
incident at production scale. |
| Redaction permanence | Extract text from your own redacted output; check
embedded thumbnails and image streams too | Overlay redaction is the default behavior of most free
tools. This test takes ten minutes and has ended careers. |
| Table structure recovery | Extract a document with nested tables and compare cell
boundaries against ground truth | Several popular parsers score 0.000 here. If documents
feed an agent, this is the number that decides whether it
answers correctly. |
| Signature longevity | Sign, then validate offline with no network access after
the signing certificate would have expired | Without PAdES B-LT, a signature that validates today
reads as “validity unknown” to an auditor in five years. |
| PDF/UA and PDF/A conformance | Convert, then validate with veraPDF | Binary and legally consequential. Pass rates across tools
range from 15 percent to 96 percent on identical files. |
| Handling of broken files | Feed it deliberately corrupted files, tiny files that
expand to consume all memory, and files that cut off
halfway through | If users upload documents, this is your attack surface.
Resource exhaustion is the most common real-world failure. |
| Metric | What to measure | Why it matters |
|---|---|---|
| Time to fix an edge case | Hours from a reported rendering or extraction defect to a
deployed fix | The single best proxy for three-year maintenance cost.
Measure it on both paths. |
| Concurrent throughput | N simultaneous server-side jobs: per-job latency and
total throughput | Single-document benchmarks tell you nothing. Several OSS
conversion tools are not concurrency-safe at all. |
| License audit | Full dependency tree, with every license resolved and
reviewed | Run this before the architecture is committed. AGPL
obligations found during legal review are the expensive
kind. |
| Agent integration quality | Point your coding assistant at the docs and have it build
a real integration; count the corrections | Most integration work now runs through an agent. If it
needs constant correction, that cost is yours every
sprint. |
10
This isn’t an argument against agentic coding. Our own engineers
ship with Claude Code and Codex daily, and Nutrient is built to be
driven by agents: an open source MCP server, typed SDKs for TypeScript and Python, llms.txt published
across every major SDK, the TypeScript client indexed on Context7, and
a one-command install that drops complete SDK documentation into your
assistant’s rule set — Claude Code, Cursor, GitHub Copilot, and JetBrains
Junie among them. We also open sourced agentic usability, a tool that runs coding agents against an SDK in isolated
sandboxes to measure how well they can actually use it — including
against our own APIs, to find where they get confused. The
question was never whether to use an agent. It’s what you point it
at.
Vendor accuracy claims are worth what you can reproduce. opendataloader-bench is a community-maintained corpus of 200 real-world PDFs with hand-annotated ground truth, Apache 2.0, with an open source evaluation harness and a public leaderboard. We run the full corpus every release with competitor libraries pinned to their latest published versions, and commit our predictions publicly.
Nutrient’s vision tier scores 0.93 overall and tops every metric — 0.96 on reading order, 0.94 on table structure, 0.87 on heading hierarchy. Standard Nutrient scores 0.889, statistically tied with docling’s 0.892 while running roughly 134 times faster (0.004 seconds per page against 0.549). By comparison, pypdf and liteparse each score 0.000 on both table structure and heading detection, and PDF.js scores 0.000 on table structure recovery — fine for rendering, disqualifying for an AI pipeline.
Two caveats we publish alongside the wins, because leaving them out is what makes benchmark claims worthless: the 0.93 figure is the vision tier, which requires a license key and is therefore run internally rather than on the public leaderboard; and the OpenDataLoader hybrid configuration beats standard Nutrient overall (0.907 against 0.889), with docling ahead on table structure among non-vision tools. Download the corpus and run it against your own documents.
We use AI, and we’re precise about where. Recognition against a known data model — key-value pairs, MRZ lines on a passport, MICR on a check, OMR on a form, layout elements from the ICR engine — is AI- and ML-powered, but bounded: it returns typed output against a schema, with per-element confidence scores. The key-value engine’s confidence score is computed from OCR character-level confidence, word-level confidence, and the known difficulty of the data type, so a date or an IBAN scores more reliably than a free-form address. Document generation, conversion, redaction execution, signature validation, and PDF/A and PDF/UA conformance involve no model inference at all — they’re binary and validator-checkable.
Where reasoning is genuinely open-ended — chart and image
description, cursive handwriting on degraded scans, the AI
Assistant’s editing agent — we don’t call it deterministic. Our
own guides say plainly that an ambiguous word can be recognized
confidently and still be wrong. That layer is wrapped in
citations, per-element confidence scores, and a per-tool
approval policy where every operation resolves to allow,
ask, or deny — so destructive actions can
be gated behind a human, or refused outright, rather than assumed
safe. That distinction is the product, not a disclaimer on it.
A team weighing a hand-rolled viewer is deciding against a different product than a team weighing a redaction pipeline. Client-side viewing, annotation, form filling, e-signing, and redaction run with no backend at all — in the browser on the web, and fully on device on iOS and Android. That often satisfies “documents never leave our control” without any infrastructure at all. Step up only when isolation, volume, or collaboration requires it.
Mobile is a first-class native target, not a wrapped web view. The iOS and Android SDKs are native, with macOS covered by the iOS SDK through Mac Catalyst. React Native and Flutter wrap those native engines; .NET MAUI takes a different route, exposing the Web SDK’s APIs through a JavaScript bridge, so treat it as a web-engine product rather than a native mobile one. One caveat worth knowing before it costs a sprint: certificate-based digital signing is not bridged in the React Native or Flutter APIs — those surface electronic and handwritten signatures, and PAdES digital signatures have to be reached through the underlying platform SDK (iOS, Android, or Web).
| Web SDK, Standalone mode | Native mobile SDKs | Server SDKs | Document Engine | DWS APIs | |
|---|---|---|---|---|---|
| Where it runs | In the browser, no backend | On device — native iOS and Android, macOS via Mac Catalyst | Inside your own application on your server, with no network
call | Your own servers, or a dedicated instance Nutrient runs for you | Nutrient-hosted, on infrastructure shared with other customers |
| Where documents go | None — documents never leave the client | None — fully on device, works offline with no connectivity | None — fully embedded, air-gap capable | None when self-hosted; region-pinned when Nutrient-managed | Processed by Nutrient; on plans without data retention enabled,
input files aren’t persistently stored |
| Best for | Viewing, annotation, forms, e-signing, redaction with no
infrastructure | Field and offline work: viewing, annotation, forms, and signing
on a phone or tablet with no connection | Backend processing, local extraction and OCR, strict
requirements that documents never leave your network | Real-time collaboration, high-volume processing, tenant
isolation | Fastest start, usage-priced, no infrastructure to run |
The requirements that surface late in an evaluation — air-gapped deployment, zero telemetry, data residency — are documented deployment paths here, not custom engagements. Nutrient is SOC 2 Type 2 audited, GDPR-compliant with US and EU regional hosting, and ISO 27001-aligned, with PDF/A archival, PDF/UA auto-tagging, and PAdES-compliant digital signatures as first-class capabilities rather than a roadmap item. Encryption-in-transit and at-rest specifics vary by product and deployment — confirm them against the security guide for the product you’re deploying.
Nutrient is the accumulated engineering of five formerly independent document companies, built on PDFium — the same engine behind Chrome and Edge — and running across Web, iOS, Android, .NET, Java, Node.js, Python, React Native, Flutter, and MAUI with one data format and one support relationship. More than 3,000 organizations use it, including roughly 15 percent of the Global 500, across more than a billion document interactions a year. That’s the thing a build has to replace, and it isn’t a viewer.
11
Get a trial key scoped to your use case and time-box it against your build path on the same corpus. Everything you build during the trial carries over to production — no rework.
Talk to a solutions engineer about where your requirements actually sit. If your scope is narrow enough that building is the better call, you’ll hear that.
Install the MCP server, pull the typed SDKs, and let your agent integrate real document operations against your own files. Judge the result the way you’d judge its build.
An honest, capability-by-capability comparison against agentic coding and open source — including the rows where building it yourself is the better fit.
For a prototype, or a viewer for files you control, yes — and that’s a good use of a coding agent. The gap opens after the demo. A working prototype and a production-safe implementation are different achievements, and the distance between them is made up of edge cases, surviving broken and hostile files, and meeting compliance standards — in a domain with a twenty-year history of published security vulnerabilities. The honest question isn’t whether your agent can produce something that works. It’s whether you can certify it’s correct on the one badly formed contract, every time, with an audit trail.
Year one, often yes — first-draft development is genuinely compressed. Cumulatively, probably not. The cost categories most exposed to compounding — maintenance, security patching, code review — are the ones independent research says are flat or worsening: refactoring fell while duplicated code rose across enterprise codebases, AI adoption measurably decreased delivery stability in Google’s DORA data, and AI-authored pull requests carry roughly 1.7 times the flagged issues of human-authored ones. Build the three-year model, not the year-one one.
When the scope is permanently narrow and you mean it, when document processing is your actual product with a funded team behind it, when you’re pre-PMF and runway matters more than engineering time, or when your real constraint is commercial rather than technical. Chapter 08 covers each with the evidence. We’d rather tell you that than oversell — and the agentic coding comparison names the specific capability rows where building it yourself is the better fit.
For basic viewing of well-behaved files, PDF.js and PDFium are solid, widely used projects. The ceiling is the problem: no certificate-based signature verification, limited PDF/UA support, no true redaction, and 0.000 on table-structure recovery in a public 200-document benchmark. Several of the other common recommendations — MuPDF, Ghostscript, iText — are AGPL with a single commercial licensing agent, so using them in a closed-source or SaaS product means disclosing your source or buying a license. See the full PDF.js comparison and why AI agents hallucinate PDF table data.
Institutional memory. When a customer reports that one scanned invoice displays a single character wrong — because the page is rotated and the font is only partly embedded in the file — someone has to understand the code well enough to fix it safely. If an agent wrote the first draft, the old assumption that the author holds the mental model no longer holds — and a Qodo survey of 609 developers found 65 percent say AI tools miss relevant organizational context during exactly that kind of work. Every AI-generated feature in production needs a named human owner who genuinely understands it.
Same corpus, same time box, same engineers, on both paths — then measure the things that surface later, not the things that surface in a demo. Critical failures across a thousand real files, redaction permanence tested by extracting text from your own output, PDF/UA conformance validated independently with veraPDF, and time-to-fix on an edge case injected a week after the build looked done. Chapter 09 has the full measurement tables.
Yes. Once you’ve decided to buy, the PDF SDK buyer’s guide covers vendor evaluation criteria, rendering engines, pricing models, and POC benchmarks. There’s also a DOCX editor SDK buyer’s guide for Word-document editing specifically.
