Industry
Software engineering for Legal
Legal software fails in three familiar ways: it leaks confidential or privileged material it should have ringfenced, it ignores the SRA obligations that shape a firm, or it demands data entry fee-earners will never do so it sits unused. The hard part is never the interface: it is confidentiality and privilege, SRA compliance, and building something busy lawyers will actually adopt. We build for that reality.
Why the domain matters
Legal work runs on two things software has to respect absolutely: the confidentiality a client is owed and the legal professional privilege that protects their communications. A law firm is also a regulated business, supervised by the SRA, obliged to run client money properly, to conduct client due diligence and anti-money-laundering checks, and to supervise its people. And it is staffed by fee-earners whose time is quite literally the product, who are busy, sceptical of administration, and quick to abandon a tool that adds friction. Software for this sector that ignores any of those three realities (confidentiality and privilege, SRA regulation, or fee-earner adoption), fails, however sophisticated the demo looked.
The market has a shape worth naming, because software lands differently across it. Large firms run heavyweight practice management and document systems and have their own IT and knowledge functions; the constraint there is integration into an entrenched estate and change management across hundreds of sceptical fee-earners. Small and mid-sized firms run leaner, often on incumbent practice-management platforms, and need software that removes real administrative load without an IT department to nurse it. In-house legal and legal-operations teams are a different buyer again (matter management, spend control, and volume work), measured on efficiency rather than billable hours. Across all of them the same non-negotiables apply: privileged and confidential material must be ringfenced, client money and regulatory obligations must be handled correctly, and the tool has to fit a working day nobody will restructure for it.
We are a senior-led team and we operate what we build, so we start from how lawyers actually work and what the firm is actually obliged to do, rather than from a product we would like to sell. The recurring failure mode in legal software is elegant systems that fee-earners will not feed, or that treat confidentiality and conflicts as an afterthought, or that assume a tidy matter lifecycle firms do not follow. We would rather build the unglamorous document automation, the conflict check, and the time-capture that survives contact with a partner between meetings than the slick interface that wins a pitch and then sits idle. The hard part here is confidentiality and privilege, SRA compliance, and adoption, and we build for that.
The challenges in legal
Confidentiality and legal privilege are absolute, not configurable
A firm owes its clients confidentiality, and privileged communications carry protection that must not be compromised. That reaches deep into the software: information barriers between matters and teams, ringfencing to prevent conflicts, careful control of who and what can ever see privileged material, and deliberate thought about where that material is processed and stored. This is not an access-control feature to bolt on later. It is a professional and legal obligation that shapes the whole architecture, and getting it wrong can waive privilege or breach confidence, which is far worse than a bug.
Fee-earners will not use software that adds friction
This is the graveyard of legal software. A lawyer’s time is the product, they are busy and sceptical, and anything that demands data entry they see as administration gets quietly abandoned, no matter how capable it is. Time that is not captured is revenue lost; matters that are not updated leave the system lying. The value is in removing steps from the fee-earner’s real day and capturing information as a by-product of how they already work, not in imposing a process nobody follows.
SRA regulation and client money reach into the software
A law firm is supervised by the SRA and must handle client money under the Accounts Rules, conduct client due diligence and AML checks, run conflict checks, and supervise its work. These are not paperwork bolted on at the end: they shape what the software must capture, evidence, separate and retain. Client account handling in particular is unforgiving; getting client money accounting wrong is a serious regulatory matter for the firm, not merely a defect, so it has to be built deliberately and correctly.
Entrenched incumbent systems everything already runs on
Most firms already run an incumbent practice-management and document-management system that is the system of record for matters, documents, time and billing. New software has to integrate with it, migrate off it carefully, or sit alongside it, because ripping it out mid-flight breaks the firm’s ability to bill and to find its own documents. Any plan that assumes a clean greenfield ignores the platform the firm depends on every hour, and the years of matter files and precedents living inside it.
A matter lifecycle that is messier than the diagram
Legal work does not follow the tidy lifecycle a product designer draws. Matters open, stall, change scope, spawn related matters, and involve documents, deadlines, correspondence and court steps in an order that varies by practice area and by client. Software that assumes a clean linear process breaks on the first real matter. Building for legal means accommodating the mess, flexible workflow, human judgement, and the reality that a partner’s experience often overrides the system’s assumptions.
High-stakes deadlines and court steps with no margin for error
Limitation dates, court deadlines and filing windows are unforgiving: a missed limitation date is a negligence claim, not a rescheduled task. Legal software that touches deadlines, court integration or e-disclosure has to be reliable in a way ordinary business software is not, because the cost of a silent failure lands on the client and on the firm’s professional indemnity. That raises the bar on correctness, alerting and audit far above what a typical CRM would demand.
What we build for legal
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Practice and case management
Matter-centric systems that hold the reality of legal work (matters, parties, documents, deadlines, correspondence and tasks), with conflict checking and information barriers built in rather than bolted on. We design around the messy real lifecycle of a matter and around fee-earners who will not do administration for its own sake, so the system captures what it needs as a by-product of how lawyers already work, and partners actually keep it current instead of quietly working around it.
Document automation and assembly
Document automation that generates letters, contracts and bundles from firm precedents and matter data, so fee-earners stop re-drafting from a colleague’s old document and stop copy-pasting party details. This is where legal software often earns its keep, because drafting is a huge share of a lawyer’s time, so we build assembly that respects the firm’s precedents and house style, keeps a human in control of the final document, and removes the repetitive typing rather than the judgement.
Time recording and billing
Time capture and billing built around the fact that unrecorded time is lost revenue and fee-earners resent recording it. We make capture as passive and low-friction as possible, tie it cleanly to matters, and build billing that handles the firm’s real fee arrangements, narratives and client account interactions correctly. Because client money and billing are SRA-regulated, we treat the accounting rules as a design constraint, not an optional module.
E-disclosure and eDiscovery support
Tooling to support disclosure at scale (collecting, de-duplicating, searching, reviewing and producing documents under the disclosure rules), where volume, defensibility and a clear audit trail matter more than anything. We build for the reality that disclosure is high-volume, deadline-bound and subject to challenge, so the process has to be reproducible and its decisions defensible, not a black box that a court or an opponent can pick apart.
Client due diligence and AML
Onboarding and due-diligence workflows that capture identity verification, source-of-funds and the risk assessment AML requires, with the record-keeping that supervision and audit demand. We build these as part of the matter-opening flow rather than a separate chore, because AML and client due diligence are regulatory obligations the firm is accountable for, so the software has to make the compliant path the easy path, and keep the evidence trail that inspection expects.
Matter management for in-house and legal ops
For in-house teams and legal operations, matter and workload management focused on efficiency, spend control and volume rather than billable hours, intake, triage, tracking, external-counsel management and reporting. This is a different buyer with different incentives from a private-practice firm, and we build for their reality: demonstrating value, controlling cost and handling volume, with the same underlying respect for confidentiality and clean records.
Where we help
A case system fee-earners actually keep current
A firm wants one place holding matters, documents, deadlines and correspondence, with conflicts and information barriers enforced. The real work is designing capture around how fee-earners already work so updating the system is a by-product rather than an extra chore, and building the conflict check and barriers in from the start. Get that right and partners trust and feed the system; get it wrong and they keep their real matter state in their heads and their inbox, and the software becomes an expensive filing cabinet nobody updates.
Document assembly that removes the repetitive drafting
Fee-earners are re-drafting the same letters and contracts from colleagues’ old documents and re-typing party details across a matter. We build automation that assembles documents from the firm’s precedents and matter data, respecting house style and keeping the lawyer in control of the final draft. The measurable win is drafting time returned to fee-earners and fewer copy-paste errors in party names and figures, removing the repetitive typing, not the legal judgement that has to stay human.
Time capture that stops revenue leaking
A firm is losing recordable time because fee-earners forget or resent logging it. We make capture as passive and low-friction as possible, tied cleanly to the right matter, so time is recorded close to when the work happens rather than reconstructed painfully at month-end. The win is recovered revenue and more accurate narratives, achieved by fitting the fee-earner’s day rather than demanding they restructure it around timekeeping they will always deprioritise.
AML and conflict checks built into matter opening
A firm needs client due diligence, AML risk assessment and conflict checking done consistently before a matter opens, with the evidence trail supervision expects. We build these into the matter-opening flow so the compliant path is the easy path (identity and source-of-funds captured, conflicts screened, risk assessed and recorded), rather than a separate chore fee-earners skip under time pressure. The value is a firm that can evidence its regulatory compliance without slowing its lawyers to a halt.
How we build for legal
We start from the fee-earner’s day and the firm’s obligations, not the screens. Before designing anything we want to see how lawyers in the relevant practice areas actually work, where the incumbent practice-management and document systems sit, and what the firm is obliged to do around client money, AML and conflicts. In legal the constraint is almost always adoption and the non-negotiables of confidentiality and regulation, so we design for the busy partner who will use this between meetings, not for the pitch.
We treat confidentiality, privilege and conflicts as architecture, not features. Information barriers, ringfencing and control over who can ever see privileged material shape the whole design and are built in from the start, because getting them wrong can waive privilege or breach confidence: consequences far graver than an ordinary bug. We would rather design the barriers carefully up front than discover a conflict or a leak in production on a client’s privileged matter.
We are blunt about what fee-earners will and will not do. Software that demands administration lawyers see as beneath their time gets abandoned, so we make the system capture what it needs as a by-product of the work (passive time capture, document assembly, information pulled from correspondence), rather than asking for data entry that will not happen. Where an idea depends on fee-earners doing admin they never will, we say so early instead of building something that sits unused.
Because we operate what we build, the people designing a client-account interaction, a conflict check or a limitation-date alert are the ones accountable when something has to be explained to a regulator, a client or the firm’s insurers. That concentrates the mind on the failure modes that actually matter in legal (a mishandled client-account entry, a missed limitation date, a barrier that leaked), and keeps us honest about trade-offs up front rather than discovering them in production on the firm’s behalf.
Regulation and compliance
A law firm is supervised by the SRA and operates under its Standards and Regulations, including the obligations around competence, confidentiality, conflicts of interest and supervision. Software that runs a firm’s matters and documents has to support those duties rather than cut across them: conflict checking, information barriers and defensible records are the software expression of professional obligations, so we build them in deliberately rather than treating them as optional configuration.
Client money is governed by the SRA Accounts Rules and is unforgiving. Where our software touches billing, disbursements or the client account, it has to keep client money properly separated, accurately accounted for and reconcilable, because getting client account handling wrong is a serious regulatory matter for the firm, not merely a defect. We treat the Accounts Rules as a hard design constraint and build the accounting and audit trail to withstand inspection.
Anti-money-laundering rules and client due diligence apply to much legal work, requiring identity verification, source-of-funds enquiry, risk assessment and record-keeping. We build these into matter opening so the compliant path is the easy path and the evidence trail is captured as work happens, rather than reconstructed under the pressure of a supervisory review. Confidentiality and legal professional privilege sit over everything, shaping how data is separated, stored and accessed.
Data protection under UK GDPR applies across all of it, because legal software holds a great deal of sensitive personal and matter data. We engineer for lawful basis, minimisation, retention and access control from the start. To be clear about the boundary: we are engineers who build software that supports these obligations, not your COLP, COFA, MLRO or compliance function. Accountability for SRA compliance, client money and AML rests with the firm and the people who hold those roles, and we build to work alongside them rather than to replace their judgement.
Integration
The incumbent practice-management and document-management systems are the gravitational centre of legal integration. Most firms already run one as the system of record for matters, documents, time and billing, along with years of matter files and precedents, so new software has to read from it, write to it, or migrate off it without breaking the firm’s ability to bill and to find its own documents. We treat coexistence and migration as first-class engineering, because the incumbent platform is not going anywhere on the timescale of a single project.
Email and the document estate are where legal work actually lives, so integration with the firm’s mail, calendaring and document storage is central rather than peripheral. Correspondence, deadlines and documents have to flow into the matter without fee-earners re-filing everything by hand, because if keeping the matter current means manual filing, it will not happen. We design that flow so information is captured as a by-product of how lawyers already communicate.
Court and HMCTS integration matters wherever the work is litigious or involves filing. As court services digitise, integrating with online filing and case systems removes manual re-keying and reduces the risk around deadlines and submissions, but it demands reliability, because a court deadline is unforgiving and a silent failure to file lands on the client and the firm’s indemnity. We build these integrations for correctness and clear alerting, not just convenience.
Client due diligence and AML providers, identity verification, e-signature, legal research and accounting systems all plug into the operational flows, and e-disclosure brings its own volume and defensibility demands. The recurring integration problem across all of this is keeping matter, party and document data consistent as it crosses systems that were never designed to agree, and doing so without ever breaching the confidentiality and privilege that separate one matter and one client from another. We treat that reconciliation, and its confidentiality boundaries, as core work.
Security and data protection
Legal software holds some of the most sensitive material an organisation can hold: privileged communications, confidential client information, matter files, identity and source-of-funds evidence, and client financial data. That is both an attractive target and a professional liability, so we build with access controls scoped to genuine need, information barriers between matters and teams, encryption in transit and at rest, and retention limited to what a lawful basis and the firm’s obligations support. Confidentiality and privilege are not features here; they are the point.
Information barriers and ringfencing deserve deliberate design, not a permissions afterthought. Preventing the wrong person from seeing a matter is how conflicts are managed and how privilege and confidentiality are preserved, so we design who and what can ever access privileged material carefully, with clear purpose limitation, rather than letting access accumulate loosely across the system. A barrier that leaks is not a minor defect: it can breach confidence or compromise privilege on a live matter.
Client account and billing flows are a direct financial and regulatory surface. We build these paths with strong authentication, careful handling of client money and bank details, and reconciliation that makes discrepancies visible rather than silent, because a client-account error is a serious SRA matter and a payment that quietly goes astray does real harm to a client and to the firm. The accounting audit trail is part of the security deliverable, not an optional log.
Because we operate what we build, security here is not a report handed over at the end. We instrument for the access patterns and anomalies that indicate a problem, keep the audit trail an investigation, a regulator, or a data-subject request would need, and treat the ability to reconstruct exactly what happened to a client’s confidential and privileged material as part of the deliverable, because in legal a breach of confidence or a compromised privilege is a professional catastrophe, not just an incident to disclose.
What changes
A system fee-earners actually feed, not work around
Because we design capture around how lawyers already work (passive time recording, document assembly, information pulled from correspondence), the system stays current as a by-product of the work, rather than becoming an expensive filing cabinet partners keep in their heads and inbox because updating it felt like administration.
Confidentiality, privilege and conflicts held correctly
By building information barriers, ringfencing and conflict checking in as architecture rather than afterthoughts, privileged and confidential material stays where it must and conflicts are caught before they become a problem, which protects the client relationship and the firm from consequences far graver than an ordinary software bug.
Regulatory obligations evidenced without grinding lawyers to a halt
Because AML, client due diligence, conflicts and client-account handling are built into the flow so the compliant path is the easy path, the firm can evidence its SRA and AML compliance to inspection while fee-earners keep working, rather than choosing between compliance and productivity as if they were opposites.
What we build for legal
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for legal?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in legal choose us
We build for how lawyers work, not how legal software wishes they did
The reason most legal software fails is that it demands administration busy, sceptical fee-earners will not do, so it sits unused. We start from the real day of a partner between meetings and design capture as a by-product of the work, because a tool that lawyers abandon, however capable, has delivered nothing to the firm that paid for it.
We treat confidentiality and privilege as architecture
Information barriers, ringfencing and control over privileged material shape the whole design and are built in from the start, not bolted on as permissions later. Getting this wrong can waive privilege or breach confidence (a professional catastrophe, not a bug), so we design it deliberately up front rather than discovering a leak on a client’s live matter.
We take SRA regulation and client money seriously
Client account handling is unforgiving and SRA compliance is the firm’s responsibility, so we treat the Accounts Rules, AML and conflicts as hard design constraints and build the evidence trail to withstand inspection. We are engineers, not your COLP, COFA or MLRO, but we build software that supports those roles instead of cutting across them.
We operate what we build
The people who design a client-account interaction, a conflict check or a limitation-date alert are the ones accountable when something has to be explained to a regulator, a client or the firm’s insurers. That keeps us focused on the failure modes that matter in legal (a mishandled client-account entry, a missed limitation date, a leaked barrier), and honest about trade-offs up front.
Common questions
How do you protect confidentiality and legal privilege in the software?
By treating them as architecture, not a permissions feature bolted on later. A firm owes clients confidentiality and privileged communications carry protection that must not be compromised, so we build information barriers between matters and teams, ringfence access, and control who and what can ever see privileged material, with deliberate thought about where that material is processed and stored. Getting this wrong can waive privilege or breach confidence, which is a professional catastrophe rather than an ordinary bug, so we design it carefully from the start rather than discovering a leak in production on a client’s live matter.
We already run a practice-management and document system, can you work with it?
Almost always, and we plan for it from the start. Most firms already depend on an incumbent platform that is the system of record for matters, documents, time and billing, along with years of matter files and precedents, so new software has to integrate with it, sit alongside it, or migrate off it carefully, never rip it out mid-flight. We treat that coexistence and migration as first-class engineering, because the incumbent system is not going anywhere on the timescale of a single project, and breaking a firm’s ability to bill or to find its own documents is how legal software destroys a working practice.
How do you get fee-earners to actually use the software?
By making it fit their day rather than asking them to restructure it. A lawyer’s time is the product, they are busy and sceptical of administration, and anything that adds friction gets abandoned no matter how capable it is. So we make the system capture what it needs as a by-product of how they already work: passive time capture tied to matters, document assembly from precedents, information pulled from correspondence, rather than demanding data entry that will not happen. Where an idea genuinely depends on fee-earners doing admin they never will, we say so early instead of building something that sits unused.
How do you handle SRA compliance, client money and AML?
As hard design constraints that shape what the software captures, separates and evidences, not as modules bolted on at the end. Client money under the SRA Accounts Rules is unforgiving, so we build billing and client-account handling to keep money properly separated, accurately accounted for and reconcilable, with an audit trail that withstands inspection. AML and client due diligence go into matter opening so the compliant path is the easy path and the evidence is captured as work happens. To be clear about the boundary: we are engineers, not your COLP, COFA, MLRO or compliance function, accountability for SRA compliance, client money and AML rests with the firm and those roles, and we build to support them rather than replace their judgement.
Can you support e-disclosure and court or HMCTS integration?
Yes, and we build both for the reliability they demand rather than mere convenience. E-disclosure is high-volume, deadline-bound and open to challenge, so we build collection, de-duplication, search, review and production to be reproducible and defensible, because a court or an opponent can pick apart a black box. Court and HMCTS integration removes manual re-keying and reduces the risk around filing and deadlines, but a court deadline is unforgiving and a silent failure to file lands on the client and the firm’s indemnity, so we build these integrations for correctness and clear alerting above all. In legal, the cost of a quiet failure is far higher than in ordinary business software, and we build to that bar.
Building for legal?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if legal is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.