Document edit QA for legal and compliance teams

The specific moment this surfaces in legal and compliance work is during a last-minute redline: a paralegal or contract manager opens a PDF or Word export, corrects a clause, and the formatting shifts in ways that are invisible until the document is printed or sent to opposing counsel. 'The text field will change to another area even if we have saved the editing' and 'editing text alters the entire line or paragraph' describe exactly what happens when tracked changes or PDF text edits interact with the document's underlying style definitions.

Legal teams don't have a designer's eye for typography, so they often don't notice that a font changed from the firm's standard to a system substitute, or that line spacing tightened in a way that makes a clause run onto a new page and break a cross-reference. They notice when a judge flags a non-compliant filing format, or when a client asks why the executed contract looks different from the draft.

The reason this hasn't been properly solved is structural: the people who suffer the problem (paralegals, contract managers) don't configure the software, and the people who configure it (IT, legal ops) don't do the editing. Nobody owns the gap between 'document looked right before editing' and 'document looks right after editing.' There's no QA step between edit and send.

A lightweight tool that runs a before/after visual diff on a document — comparing the pre-edit version to the post-edit version and flagging any change in font, size, spacing, or pagination that wasn't part of the intended edit — would catch these issues in seconds. It doesn't need to fix the problem; it needs to surface it before the document leaves the building. The need recurs every time a document is edited and sent externally, which in a law firm or compliance-heavy company is dozens of times per day.

What to build

Build a Windows desktop and web application that takes two versions of the same document (PDF or DOCX), runs a character- and paragraph-level visual diff, and produces a report that separates intentional content changes from unintended formatting changes — specifically flagging font substitutions, spacing shifts, and pagination changes — so a paralegal can confirm the document is visually stable before sending.

Where to start

Start with litigation support teams at mid-size law firms that file electronically with courts that have strict formatting rules — where a font or spacing violation means a rejected filing, giving the pain a concrete, immediate cost that justifies a new workflow step.

The hard part

The hardest first-customer problem is that legal teams won't adopt a standalone QA step unless it integrates into their existing document management system (iManage, NetDocuments, SharePoint), and those integrations require either API access or enterprise IT approval — making the sales cycle slow for a product that should feel lightweight.

How it makes money

Per-seat annual subscription, with a team tier that covers a practice group; pricing anchored below what a single rejected court filing costs to refile.