How to Choose Legal Software: 5 Questions That Expose Weak Systems

A vendor demo shows the happy path, because that is what a demo is for. The problem is that firms then buy on the happy path and meet the system properly six months later, on a Friday, when something has gone wrong.

You do not need to be adversarial to avoid that. You need to ask what happens on the unhappy path, and to prefer answers that describe a mechanism over answers that describe an intention. "We would never do that" is an intention. "The database rejects it" is a mechanism.

Ask to see the most privileged account amend an audit entry. What you want is a refusal, and specifically a refusal that comes from below the application.

If the answer is that administrators simply do not have that button, ask what happens on a direct database connection, or through the API, or during a support intervention. A guarantee that holds only on one code path is not a guarantee; it is a convention.

This one question exposes whether the system keeps fiscal records or merely displays them. Change the firm's tax percentage, or its base currency, and then reopen an invoice issued last year.

If the historical document now shows different figures, the system is computing history from current settings, and every report the firm has ever exported was provisional. Issued documents must carry their own rates and their own currency, frozen at issue.

Give the system a conflict that sits one layer up — a party that shares a director, or is owned by an entity you already act for — and see whether it surfaces at intake or not at all.

Then ask when the check ran relative to the matter being created, and where the result is stored if the search found nothing. Firms are rarely undone by conflicts they saw. They are undone by conflicts they cannot prove they looked for.

Ask to see the same screens through a junior account, then ask where the restriction is enforced. If the demonstration is that certain menu items disappear, the boundary is cosmetic.

The follow-up worth asking: if that associate's browser sent a request for another firm's matter directly, what comes back? The correct answer is "nothing, because the database filters it", not "they could not construct that request".

Ask this before signing, not after. What form does the data leave in, how long does the firm have, and what happens to documents you are obliged to retain for years after the engagement ends?

Retention obligations on fiscal and client records usually outlive any software contract, so a system whose answer is "we delete everything at cancellation" is creating a compliance problem for you. So is one that cannot tell you precisely what it holds.

Taking the questions in order, and without softening any of them:

• Editing history: database triggers reject UPDATE and DELETE on audit rows for every role, including administrators and the service role the application runs as. There is no privileged path, because the privilege does not exist.
• Changing a rate: nothing happens to last year. Issued documents carry their own per-line rates, currency and conversion rate, frozen at issue, and always outrank current settings. Changing base currency is a guided operation that re-bases reporting without touching invoice amounts.
• Conflicts one layer up: screening runs before the matter row is created, across clients, organizations, directors, UBOs and external counsel, with fuzzy matching. Cleared searches are stored as records in their own right.
• Associate access: enforced by row-level security in the database, keyed on firm and role. A request for another firm's row returns nothing regardless of the route it arrives by.
• Leaving: an active firm can export its data. We say plainly what a lapsed account can and cannot do, and we do not pretend a subscription lapse resolves your retention obligations.