Legal Practice Management Software Case Study

The challenge

Cavory set out to build a practice product for lawyers and law firms that had to exist on every surface a firm actually uses, a web application, an Android app, an iPhone app and a Windows desktop application, without the four drifting into four different products. The harder constraint was where the data lives. Legal documents and matter records are exactly the material a firm is least willing to hand to somebody else's infrastructure, so the system had to run against a firm's own in-house servers as readily as against the cloud, and had to keep the two in step rather than forcing a choice between them. On top of that the product was expected to work with the tools firms already run their business on, with synchronisation to QuickBooks, Salesforce and G Suite, and to support several lawyers in a firm collaborating on the same matter rather than each holding a private copy.

The approach

The system was built from scratch, because the deployment requirement rules out most of what could otherwise have been assembled from existing parts, a product that must run identically on a firm's own server and in the cloud cannot be designed as a cloud application with an export feature. The synchronisation utility was treated as a first-class component of the architecture rather than an integration added afterwards, covering both the in-house to cloud direction and the third-party APIs, so a record created in any client on any deployment reconciles into one matter file. Platform coverage was handled by keeping the business logic and data model on the server side and treating the web, Android, iPhone and desktop clients as interfaces onto it, which is what stops four platforms becoming four behaviours. Data security shaped the design from the first decision rather than being reviewed at the end, since the material being stored is privileged.

The outcome

What Cavory ended up with is a practice system a firm can adopt without first deciding to move its documents off its own premises, which for a legal practice is usually the decision that stalls a software purchase. A lawyer working from a phone, a laptop or a desktop is working on the same matter file, and colleagues in the same firm are collaborating on one record rather than exchanging versions of it. Because the accounting, CRM and productivity tools the firm already runs are synchronised into the same records, the practice data and the commercial data stop being two separate accounts of the same matter.

The interesting constraint here was not the number of platforms; it was being told that the product must run on the client’s own servers and in the cloud, and that the two must stay in step. That single requirement decides the architecture, and it has to be decided first.

Why “it must run on our own servers” is an architecture decision, not a deployment option

A cloud application assumes things a self-hosted one cannot. It assumes a single environment the vendor controls, one version in production, services that are always reachable, and configuration that can be changed by the people who wrote it.

Take those away and a great deal changes at once. Every environment-specific value has to become configuration rather than a constant. Schema migrations have to run in an environment nobody on the build team can log into. There has to be an answer for a firm running a version six months behind the cloud. A product that must run on a customer’s own hardware is a distributed product, and distribution is a property you design for at the beginning or retrofit at great cost.

This is why the system was built from scratch rather than assembled. Most of what could have been reused assumes the cloud case.

What a two-way synchronisation utility has to decide

Sync is the component people underestimate, because the happy path is trivial and the interesting cases are all the other ones. Any synchroniser between an in-house deployment and a cloud one has to have an answer for four questions, decided deliberately rather than discovered:

• What happens when the same record is edited in both places between syncs, and which edit wins
• How a deletion is represented, given that an absent record and a deleted record look identical
• How the two sides agree on ordering when their clocks do not agree
• What happens when the same change is delivered twice, which it eventually will be

Treating that as a first-class component rather than an integration added afterwards is the difference between a matter file that reconciles and two divergent copies of a firm’s records.

Why four clients did not become four products

The business logic and the data model stayed on the server. The web application, the Android app, the iPhone app and the Windows desktop application are interfaces onto it.

The alternative — each client implementing its own view of what a matter is — fails slowly and invisibly. One platform gets a validation rule the others do not, a status transition is allowed on mobile and refused on desktop, and the bug reports blame the platform rather than the divergence. When the same rule is written four times, the question is not whether the four will disagree but when.

Why the third-party integrations are the same problem again

QuickBooks, Salesforce and G Suite each hold their own idea of a client, their own identifiers and their own rate limits, so synchronising with them is the reconciliation problem repeated three more times against systems that will not change to suit you.

Regulated and privilege-bound sectors ask for this shape of product more often than they are offered it, because it is genuinely more work than shipping a cloud application. It is the sort of constraint that belongs in the first week of a custom software engagement rather than in a change request during acceptance.