A case-management system a law firm has run for over six years
Custom CRM for a legal practice: matters, procedural deadlines, fixed-fee agreements and client money in one system. Six years in production across three offices.
- Client
- Name withheld
- Industry
- Legal practice
- Services
- Custom CRM, management accounting, messenger booking bots, SMS gateway
- Tech stack
- Fat-Free Framework · MariaDB · Telegram Bot API
- Languages
- RU
What this system is
Off-the-shelf CRM sells pipelines and deals. A legal practice does not run on deals. It runs on matters with procedural deadlines, fixed-fee agreements paid in instalments, physical case files that leave the office in someone’s hands, and a duty to tell the client what happened. This system was built around that.
Six years in production, three offices
A demonstration can be built in a fortnight. A system a working practice has not abandoned in six years is a different class of evidence.
- Court cases
- 626
- Appointments · meetings
- 1443 · 3674
- Client requests
- 2119
- Internal messages
- 57 136
- Agreements · payments · cash
- 441 · 930 · 556
- Months of accounting history
- 72
The system moved to its current server in March 2021 carrying its history with it — the accounting ledger alone spans 72 months. The outcome the firm reports: the monthly management report used to occupy one member of staff for about two working days; it now takes tens of minutes. (Owner-reported, not independently measured.)
What general-purpose CRM gets wrong here
Physical files move around
A matter is not only rows in a database; it is a paper folder a specialist signs out and is expected to bring back. The system tracks who took which file, when, and whether it came back. Software usually ignores this because it is not digital — and the office keeps a paper log beside the digital one.
A deadline is not a due date
Each step carries the date it was issued and, separately, a control date by which something must have happened. Different fields, because they answer different questions; collapsing them loses the one with legal weight.
Money arrives in pieces
Contract value and paid amount are held separately, and payments are hierarchical: an instalment belongs to a parent obligation. A flat payments table cannot express a half-fulfilled plan.
The part worth showing to another engineer
Metrics are data, not code
The system stores metric definitions — name, category, calculation type, formula, unit, charting, display order, hide-at-zero. A new indicator is configured, not developed.
Outbound is a queue, not a call
Notifications go through a store with a polymorphic source reference, status, timestamps and a recorded error. A failed message is visible and retriable rather than lost.
Deletion keeps its evidence
Soft delete records who and when; sensitive agreements carry a visibility flag so they can be withheld from some internal roles.
Profitability is measured per service line, not per hour: the firm works to fixed-fee agreements, so the useful figures are average contract value by service line and its movement over time. Also in the system: booking bots on messengers, SMS through the firm’s own gateway rather than a per-message reseller, role-based access, and the advertising account balance surfaced inside the CRM.
Stated plainly
A case that claims everything is believed on nothing.
- No time tracking and no hourly billing — profitability is computed from contracts and service lines, which is what this firm’s model needs.
- No automatic feed from the court records system. Deadlines are entered by staff. Connecting to it is the obvious next step, not a hidden gap.
- Lead-source reporting starts when the booking form launched (June 2026), so earlier records carry no channel.
- Performance is measured in money only. There is no separate quality score.
The practice runs its casework, its deadlines and its client money in one system shaped to its own procedure, on its own server, for over six years and counting.