Build vs. Buy: Should Your Team Maintain a PDF Viewer?

Displaying a PDF in your web app looks like a solved problem — until it's yours to own. What starts as "just render this document inline" turns into a standing commitment: a rendering library to keep current, mobile quirks to chase, and a viewer that has to keep working across every browser your customers use. For an enterprise team, the real question isn't can we build a PDF viewer — it's whether that's where your engineers should be spending their time.

Here's a practical way to think through the build-vs-buy decision.

The hidden cost of "build"

Rendering a PDF on the web is deceptively deep. A viewer that feels simple to your users has to handle a long tail of complexity underneath:

• The format itself. PDFs vary wildly — fonts, forms, annotations, scanned images, oddly structured files exported by tools you don't control. "It works on my test file" is a long way from "it works on every file our customers upload."
• Cross-browser and mobile. Rendering has to hold up across desktop and mobile browsers, with touch gestures, zoom, and responsive layouts that don't break on a phone.
• Performance. Large documents can't freeze the tab or balloon memory. Getting this right is ongoing work, not a one-time fix.
• Maintenance forever. Browsers change, libraries release breaking updates, and the viewer you shipped last year needs attention this year — indefinitely.

None of this is glamorous, and none of it differentiates your product. It's undifferentiated heavy lifting: essential to get right, but not something a customer will ever choose you for.

When building still makes sense

Buying isn't automatically the answer. Building your own viewer can be the right call when:

• Document viewing is your core product — if the viewer is the thing you sell, you'll want full control of it.
• You have deeply custom requirements that a general-purpose viewer can't meet, and you have the team to own them long-term.
• Strict constraints (air-gapped environments, bespoke security review of every dependency) make an external component a non-starter.

If none of those describe your situation, the maintenance cost usually outweighs the control.

What "buy" actually buys you

For most teams, the goal is simple: documents render cleanly inside the app, and engineering moves on. That's the case for an embeddable viewer like TruPDF — a drop-in PDF viewer that displays documents inline on the web, with no plugin and no forced download. You embed it where you need it, and the rendering, browser support, and upkeep stop being your team's problem.

The trade you're making is control for leverage: slightly less bespoke behavior, in exchange for not owning a viewer's roadmap.

A checklist for the decision

If you're weighing it for an enterprise product, walk through these:

1. Is document viewing a differentiator, or table stakes? If it's table stakes, lean buy.
2. What's the true maintenance cost over 2–3 years — not just the initial build? Include the browser/library churn.
3. How does it need to scale across your web properties and teams? A component you embed once and reuse beats re-solving it per app.
4. What are the security and integration requirements? Evaluate any viewer against how it embeds, what it loads, and how it fits your review process — and ask the vendor directly.
5. Who owns it at 2 a.m. when a customer can't open a document? Be honest about whether your team wants that pager.

The answers usually point one way for teams whose product isn't the viewer itself.

Wrapping up

Building a PDF viewer is rarely a one-time project — it's a long-term commitment to work that doesn't set your product apart. Unless document viewing is your core offering, embedding a viewer lets your engineers spend their time where it actually differentiates you.

If you're at that decision point, take a look at TruPDF and see whether a drop-in viewer fits how your team ships.