Why legal software needs a compliance-first build

Building software for most industries means satisfying rules about how a business handles data: who can see it, how long it is kept, how it is protected. Legal technology has all of that, and it adds something most other verticals do not. The product's own behavior, along with how it stores information, can put it inside a body of law it was never meant to touch: the rules against unauthorized practice of law, generally shortened to UPL.

This page is about why that difference means legal software has to be designed with these questions in mind from the start, not reviewed against them once the design is done.

The line legal software can cross that other software cannot

A tax preparation tool can calculate a specific number for a specific taxpayer and stay inside its lane, because tax preparation software is a well-established, separately regulated category. A tool that reviews a person's specific contract and tells them what to do about a specific clause is standing much closer to what a lawyer does for a client, and the closer it stands, the more it risks being read as practicing law without a license.

There is no single national definition of what crosses that line. UPL is regulated separately by each of the fifty states, and the National Center for State Courts and the American Bar Association describe the result as a real varied continuum of scope and clarity: some states have specific statutes addressing software and AI tools, most do not, and enforcement priorities differ even where the underlying rule looks similar [1]. A feature that is comfortably inside the line in one state can be a real question in another, and a nationally distributed product has to design for the strictest plausible reading rather than the most permissive one.

Two states have moved recently, and the direction they moved in is worth understanding because it shapes where the rest of the country may go. Colorado adopted a nonprosecution policy in 2024 and 2025 that deprioritizes UPL prosecution against developers of legal-help technology tools specifically, reasoning that most developers of these tools are not lawyers and are still delivering something the person needed [2]. Texas went further and amended its UPL statute to exclude computer software from the definition of unauthorized practice altogether, conditioned on the product clearly disclosing that it is not a substitute for an attorney [3]. Neither change means the line has disappeared nationally. It means two states have decided that a well-disclosed tool serving an unmet need is not the target the UPL rules were written for, and other states have not yet made that same call.

Why this is a design question, not a legal-review question

The instinct is to treat UPL as something legal counsel checks at the end, the way a privacy policy gets reviewed before launch. That instinct undersells how deep the question goes, because several of the decisions that determine where a product lands on this line are product decisions made early: does the tool present a single recommended answer or a set of options with tradeoffs explained. Does the copy say "you should" or does it say "here is what people in this situation typically consider." Does the flow end with the user making their own decision, or does it end with the product deciding for them. Those choices shape the UPL exposure as much as anything a lawyer reviews afterward, and unwinding them after the product ships is a rebuild, not a copy edit.

The same is true of confidentiality. ABA Model Rule 1.6(c) requires a lawyer to make reasonable efforts against unauthorized disclosure of client information [4], and if your product stores or transmits that information, the lawyer's ability to meet that duty depends entirely on decisions your team made about access control, encryption, and logging, most of which are architecture decisions rather than settings a compliance reviewer can toggle later. Avoiding unauthorized practice of law in product design works through what those early product decisions actually look like.

The economics that make this affordable now

The reason to build this way is that the obligations above are, like the regulatory obligations in every industry we build for, close to specifications once you read the actual rule text rather than a summary of it. "The lawyer must make reasonable efforts to prevent unauthorized access to client information" is close to a test case already: does an unauthorized user's request for a client record succeed or fail, and does the attempt get recorded.

What used to make this kind of exhaustive checking impractical was cost. Writing several hundred narrow checks against a full set of state-by-state and rule-by-rule obligations was weeks of work that shipped no visible feature, so it lost every prioritization argument to something a customer could see and pay for. That constraint is largely gone. When code is close to free to generate, the checks that used to be unaffordable become a specification exercise and a test run, which is the argument we make across every regulated vertical, laid out in more depth in our eval-driven development guide.

That does not mean generated code is automatically trustworthy here. Veracode's spring 2026 testing across more than 150 models and 80 coding tasks found only 55 percent of generations produced secure code, even as syntax correctness ran above 95 percent [5]. A generated confidentiality control that compiles and looks right is not the same thing as one that has been verified against the actual obligation, and the difference matters more in legal software than almost anywhere, because the thing being protected is privileged information a lawyer is ethically bound to guard.

What this does not settle

Nothing in this page, or in this guide, determines whether a specific product in a specific state crosses into unauthorized practice of law, or whether a specific confidentiality control satisfies a specific bar's expectations. Those are legal questions that depend on facts a lawyer needs to review, not a generic build guide. What a compliance-first build does is make sure the product's behavior reflects a real decision, made early and on purpose, rather than an accident of what was fastest to ship.

If you are scoping a new legal technology product or reviewing one already in the market, get in touch, and see compliance gaps in legal software for how we approach an audit of an existing build.