No firm sets out to run on eleven tools.
Stacks are not designed. They accumulate, one reasonable decision at a time, until the cost of moving between them becomes a permanent tax on everyone's day.
Last reviewed
Evaluate a law firm technology stack by counting handoffs rather than tools. Choose the system of record first, weigh implementation as heavily as capability, test with your own matters, and consolidate only where disconnection is actually costing the firm time or money.
How a stack accumulates
Every one of these decisions was correct at the time. The problem is not any single choice. It is that no one was choosing a system, so the firm ended up with a collection.
- A calendaring problem is solved with a scheduling tool
- A signature problem is solved with an e-signature tool
- A billing problem is solved with a billing tool
- An intake problem is solved with a form builder and a spreadsheet
- A communication problem is solved with a messaging app
- A document problem is solved with a folder convention nobody wrote down
- A reporting problem is solved by exporting everything into a spreadsheet each month
The real cost of a stack is not the sum of its subscriptions. It is the hours the team spends being the integration between them.
Six layers worth thinking about separately
The system of record
Where matters, clients, and the work surrounding them live. Everything else attaches here, so choose it first.
Communication
Email, messaging, and client-facing conversation. Usually already decided by the firm's Workspace or Microsoft choice.
Documents
Storage, drafting, templates, and signature. Often the layer firms are most attached to and least willing to change.
Money
Time capture, invoicing, payments, accounting, and reporting. The layer where disconnection is most expensive.
Specialist tools
Practice-specific software that does one thing well. Worth keeping when the specialism is real.
Intelligence
AI capability, either embedded in the system of record or standalone. Its usefulness depends on what it can see.
How to evaluate honestly
- 01
Start from the work, not the feature list
Map one matter type end to end before looking at software. Feature comparisons are only meaningful against a known process, and every vendor's list looks complete in isolation.
- 02
Count the handoffs, not the tools
The cost of a stack is measured in duplicate entry, context switching, and lost status. Two tools that pass information cleanly cost less than one tool used two ways.
- 03
Weigh implementation as heavily as capability
Ask who configures the system, how the firm's existing information moves, how each role is trained, and what happens in the months after go-live.
This is where adoption is won or lost, and it is the part most easily glossed over in a sales process.
- 04
Test with your own matters
A demonstration using the vendor's example data proves very little. Ask to see an ordinary matter from your practice move through the system.
- 05
Ask the hard data questions early
Export format, access, storage, retention, confidentiality, and what happens to firm information if the relationship ends. These answers are much easier to obtain before signing.
- 06
Plan the exit before the entry
A firm that knows how it would leave a system negotiates and adopts more confidently than one that has not considered it.
When to consolidate, and when not to
Signals that consolidation will help
- The same information is entered in more than one place every week
- Nobody can answer the status of a matter without asking a person
- Billing requires assembling inputs from three or more systems
- Reporting means exporting to a spreadsheet each month
- New team members take months to learn the unwritten process
- Tools were chosen individually and none of them is the center
Reasons to keep a tool where it is
- A specialist tool is doing something genuinely well that a suite would do adequately
- The team has deep expertise in a tool and adoption elsewhere is fragile
- A regulatory, court, or client requirement mandates a specific system
- The tool integrates cleanly and creates no duplicate entry
- The switching cost clearly exceeds the coordination cost being paid
- The firm is mid-transition already and stacking changes would be reckless
Questions about evaluating firm software
- How many tools should a law firm use?
- There is no correct number. The useful question is how many places a person must visit to complete one ordinary task, and how often the same information is entered twice. A firm with six well-connected tools is in better shape than a firm with three disconnected ones.
- Is consolidating into one system always better?
- No. Consolidation reduces coordination cost but increases dependence on a single vendor and can mean giving up a specialist tool the team genuinely relies on. It is worth doing when the tools being replaced are the ones causing duplicate entry and lost status, and worth resisting when it would replace something excellent with something adequate.
- What should a firm evaluate first?
- The system that holds matters and the work surrounding them, because everything else attaches to it. Choosing that layer first, then deciding what connects to it, avoids the common path of accumulating point solutions and later discovering none of them can be the center.
- How much should implementation matter in the decision?
- More than most firms weight it. Software that is well matched to the practice but poorly implemented produces worse outcomes than an adequate tool configured carefully around how the firm works. Ask specifically what the implementation includes and who does the work.
- What questions should we ask about data?
- How data is exported, in what format, and at what notice. Who can access it. Where it is stored and for how long. How client confidentiality is handled. Whether firm data is used for anything beyond serving the firm. Ask these before signing, not during a migration.
- How should a firm evaluate AI features?
- Ask what information the AI can see, what it does with it, what it produces, and who reviews the output before it reaches a client. A feature that works across the firm's connected information solves different problems than one that works on a single document, and both can be useful.
- How long should a rollout take?
- It depends on firm size, systems, and scope, and any vendor who answers with a fixed number before understanding the practice is guessing. What matters more is whether the rollout is staged so the firm keeps operating throughout.
Continue reading
- Building connected law firm workflows
Map the work before evaluating the software that has to carry it.
- Running a law firm on Google Workspace
What Workspace covers well, and the operational layer it was never designed to be.
- Makase Law compared with Clio
A balanced look at two different approaches to running a firm.
- AI operating system for law firms
How to evaluate AI features by what they can actually see.
Talk through your stack with us.
Bring the tools you use today. We will be direct about what Makase replaces, what it connects to, and what you should keep.