Averon Legal Systems is a SaaS platform for UK costs lawyers managing CPR Part 47 and Part 36 matters. It replaces the combination of spreadsheets, email, and shared drives that most costs practices use with a purpose-built system: matter lifecycle management synchronised with CPR procedural deadlines, automated alerting, structured document management, role-based dashboards, and a client portal. Building it required navigating a specific set of constraints simultaneously — CPR procedural requirements, SRA compliance obligations, GDPR data handling, and multi-tenant security. This is the story of how we did it.
The Brief
The problem statement was clear: UK costs lawyers are managing complex, deadline-sensitive matters in spreadsheets, and the consequences of missing a CPR deadline — cost sanctions, loss of right to assessment — are severe. The brief was to build a purpose-built platform that modelled the CPR Part 47 procedural timeline explicitly, calculated deadlines automatically from trigger events, and alerted fee earners and supervisors with enough lead time to respond. Everything else — document management, client portal, employee dashboards — was scoped in once the core deadline engine was defined.
The Compliance Constraints
Before writing any code, we mapped the compliance requirements. From CPR: the platform needed to model CPR Part 47 procedural stages accurately — including the variable timelines that depend on trigger events rather than fixed dates. From the SRA: client confidentiality requirements meant role-based access controls needed to enforce matter-level isolation, not just department-level. From GDPR: all client data needed to be stored with appropriate encryption, data processing agreements needed to be in place with every third-party service, and a Data Protection Impact Assessment was required before processing personal data.
Architecture Decisions
The core architecture decision was the choice of Supabase as the database layer. PostgreSQL's row-level security (RLS) policies allow access control to be enforced at the database level — meaning that even if the application layer had a bug, a user could not access data belonging to another tenant. This was a non-negotiable requirement for a multi-tenant legal platform. We built the entire access control model in RLS policies before building any application features, then tested it independently before connecting the application layer.
Building the Multi-Tenant Security Model
Multi-tenancy in a legal platform requires more than a tenant_id column on every table. Every query must be scoped to the authenticated user's tenant. Every API endpoint must validate that the requested resource belongs to the caller's tenant. Every file upload must be stored in a tenant-namespaced path with access policies that prevent cross-tenant access. We implemented and tested this model before building any user-facing features — then treated any cross-tenant data access, however unlikely, as a critical security defect throughout the QA process.
The CPR Deadline Engine
The deadline engine is the core of the product. It models each CPR Part 47 procedural stage as a state in a matter lifecycle, with transitions triggered by user actions (serving the bill, filing the notice of commencement, receiving points of dispute). Each transition calculates the next deadline from the trigger date and the applicable CPR timeline. Advance warning alerts are configurable: a supervisor can set a firm-wide default (alert at 14 days and 7 days) and override it per matter. All deadline calculations and alerts are logged in the audit trail.
The Client Portal Challenge
The client portal — allowing clients to view their matter status and shared documents — introduced an additional access control complexity. Clients authenticate separately from fee earners and must see only their own matter. Document visibility must be controlled at the document level: a fee earner can mark specific documents as client-visible, with the remainder remaining internal. We built the client authentication as a completely separate session context from the firm authentication, with no shared session state, to prevent any possibility of privilege escalation.
What We Learned
- •RLS-first architecture is the correct approach for multi-tenant legal software — it makes the security model testable independently of the application.
- •CPR deadline modelling requires legal input at the design stage, not just the QA stage. We engaged a costs lawyer to review the procedural model before building it.
- •Client and firm authentication must be completely separated — shared session infrastructure creates privilege escalation risk that is difficult to fully eliminate.
- •Audit trail design is an architectural decision, not a feature. Deciding what to log after the system is built produces an incomplete and inconsistent record.
- •Beta partners surface edge cases that no amount of internal testing anticipates. The most valuable thing you can do in the first month of beta is watch real users use the system.
Averon Legal Systems is currently in beta for UK costs practices managing CPR Part 47 matters. If your team would like early access, get in touch with Two Bit Digital.
Get In Touch →