A codebase that knows every firm by name
Your first firms each had a reasonable request. One needed an extra approval step for a certain matter type. One wanted a different checklist for residential and commercial work. One needed certain documents to be signed off by a partner before going to the client. Your developers added each as a small change: if firm is X, do this.
Two years later there are dozens of these checks. A change to the approval flow has to be tested against every firm's variation. A bug fix for one firm breaks another. New developers are afraid to touch the workflow code, and onboarding a new firm with a slightly different process takes a developer and a release.
How the special cases pile up
Law firms differ in how they run matters, even within the same practice area. Their risk and supervision rules, matter types, approval steps and client requirements vary, and they expect their software to follow them. Saying yes was right commercially. Putting each yes into code is what caused the problem.
- There was no configuration model, so code was the only place to put firm-specific rules.
- Each request was built under deadline, in the quickest way.
- Similar requests from different firms were built differently.
- Nobody kept a list of which firms have which variations.
- Tests cover the standard flow, not every firm's version of it.
What the sprawl costs
Development slows as every change has to account for every firm. Bugs appear in firms nobody was thinking about, sometimes in workflows that matter for supervision or client care. Onboarding new firms needs engineers. And the product becomes harder to explain: sales cannot say what the product does, because it does something slightly different everywhere.
There is a risk angle too. If a firm's approval step is silently skipped because of a code change aimed at another firm, the firm's own supervision process has failed, and your product was the cause.
How we replace special cases with configuration
What we build turns firm variations into settings, carefully, without changing what any firm experiences.
- An inventory of every firm-specific check in the code: what it does, which firm it serves, and whether the firm still relies on it.
- A configuration model covering the kinds of variation firms actually need: matter types, workflow steps and their order, approval rules by role, required documents, checklists and notification rules.
- Characterisation tests that record how each firm's workflow behaves today, so the move to configuration can be proved to change nothing.
- Migration of each special case into configuration, one at a time, with its tests passing before the code check is removed.
- An admin screen for your onboarding and support team to set up and change firm configuration, with validation to stop impossible setups and a history of changes.
- A rule for future requests: if a firm's need fits the configuration model, it is set up; if not, the model is extended deliberately rather than a special case added.
| Firm variation | Before | After |
|---|---|---|
| Extra approval for a matter type | Code check on firm ID | Workflow step in configuration |
| Different checklists by work type | Separate code paths | Checklist per matter type |
| Partner sign-off before sending | Hard-coded rule | Approval rule by role |
| Client-specific document set | Custom code | Required documents setting |
| New firm with small differences | Developer and a release | Admin screen setup |
A new firm with its own approval rule
A new firm needs a second fee earner to check certain documents before they go to the client. Your onboarding lead opens the admin screen, adds an approval step for that document type, requires a second fee earner, and saves. The validation confirms it fits the workflow. No developer is involved, no release is needed, and when your team changes the approval flow next month, the tests confirm this firm's rule still works along with everyone else's.
Is your codebase full of firm names?
- Your code checks firm IDs to decide what the workflow does.
- Onboarding a new firm with small differences needs a developer.
- Fixes for one firm have broken another.
- Nobody has a complete list of each firm's variations.
- Developers avoid changing the workflow code.