How Page built its AI-powered legal platform on reliable document infrastructure

Reviewing massive VA disability files demanded a reliable PDF viewer

VA disability law is important and consequential work, but the people doing it have often been underserved by technology. Many Page(opens in a new tab) customers are veterans themselves, or advocates who entered the field to help veterans navigate a complex bureaucracy and secure the benefits they’re legally entitled to. Page set out to give them better tools for doing that work.

Documents sit at the very center of the challenge. A single veteran’s C-file can run 4,000 to 5,000 pages, and even 50,000 pages in extreme cases. Practitioners have traditionally reviewed those files manually in Adobe, scrolling through one giant PDF for the dates, conditions, evidence, and procedural details a case turns on. Page began by using AI to turn those records into searchable chronologies and has since grown into an end-to-end workflow platform for VA disability law.

But in legal work, an AI-generated answer isn’t enough; the information has to be referenceable. Every fact Page surfaces needs to lead practitioners back to the underlying source so they can review the documents and verify facts for themselves. That made PDF viewing an embedded, core flow inside Page rather than a feature at the edge of the product. In Page’s early days, an open source viewer was enough. As the company began serving larger firms, the requirements changed. The document experience needed to be both extensible and performant. Features the library didn’t support had to be custom-built and maintained. Large files could stall or crash. Worse, viewers sometimes opened to the wrong page, even though practitioners view and review files in Page thousands, even tens of thousands, of times each day.

Page tried multiple open source viewers, but every migration introduced another round of maintenance and bugs. By the third or fourth attempt, the team knew it needed a document layer it could rely on instead of continually rebuilding. Nutrient provided the extensibility, reliability, and support Page needed to make that core experience dependable.

How Page rebuilt its document layer on Nutrient Web SDK

Page adopted Nutrient Web SDK as the document foundation beneath its platform, and the company uses it today for PDF viewing, annotations, and form filling. The viewer powers Page’s core review experience. When AI surfaces an important fact from a veteran’s record, practitioners can move directly back to the underlying page and verify the information themselves. Instead of separating AI output from the source material, Page keeps the two connected inside the same workflow.

That same document layer is becoming increasingly important elsewhere in the product. Page uses Nutrient for form filling as it works to move information extracted by AI directly into the structured VA forms practitioners ultimately submit. The goal isn’t to add document features for their own sake, but to make the work itself flow more naturally inside Page.

Implementation was handled largely by Page’s frontend team using Nutrient’s SDK documentation. Because the viewer is such a core piece of infrastructure, the integration required careful testing, but the team found the SDK straightforward to integrate and maintain once it was in place. Nutrient’s support team was also an important part of the decision: Page wanted a partner it could reach when problems arose, with a commercial model flexible enough to fit the way its business operates.

The result is exactly what Page wanted from a piece of core infrastructure: a document layer that does its job without demanding constant attention from the engineering team.

A document layer Page no longer has to think about

Before Nutrient, Page’s document layer demanded attention for all the wrong reasons. Open source viewers could crash, stall on large files, or open to the wrong page in a review flow used thousands of times each day. Engineers were also spending cycles maintaining custom forks and repeatedly migrating between viewers.

With Nutrient in place, that category of problem largely receded. Page gained a document layer that’s dependable enough to sit at the center of the product without becoming a constant engineering concern. For Gruber and team, that’s exactly what good infrastructure should do: work reliably, support what the product needs, and stay out of the way.

Results

Building toward one place where the work gets done

For Page, reliable document infrastructure is a means to a larger end: giving practitioners better tools for consequential work. As Gruber put it, “some of the people doing the most important work have access to the worst technology.”

Page wants to give those practitioners something better. And, as Gruber sees it, Nutrient plays an indirect but important role in helping Page “deliver a great experience for those people” in an area of law that technology has often neglected.

That ambition is now pushing Page beyond document review. The long-term vision is to become one place where practitioners can get their work done — from reviewing enormous case files and verifying AI-generated information, to completing forms, drafting documents, and eventually handling more of the work that still pulls them into separate tools today.

Page has already begun exploring that next phase with Nutrient’s Document Authoring SDK, with the goal of bringing a native, Word-like drafting experience into the platform. Over time, the document layer can continue expanding with Page while remaining what Gruber believes good infrastructure should be: reliable, flexible, and largely invisible.

The result is more than a better document experience. It gives Page more room to focus on building the software its customers should have had all along.