Every major CLM was built for in-house procurement at large companies. Here's where the mismatch breaks down for the people doing client work.
When attorneys at solo and small firms try to evaluate the major contract-management platforms, they usually have the same experience. They sit through the demo. They see a polished tour of approval matrices and vendor intake forms and procurement dashboards. They nod politely. Then they walk out and ask the same question: what does any of that have to do with how I actually work? The answer is: almost nothing. Legacy CLM wasn't built for them. It was built for somebody else entirely.
The contract lifecycle management category was built in the 2000s and 2010s for a specific buyer: the in-house procurement team at a large company. The original use case was managing the flow of vendor contracts — the company is the buyer, vendors send paper in, internal stakeholders need to approve at various thresholds, signed contracts get filed for audit.
Every architectural decision in legacy CLM was made to serve that user. Multi-stage approval workflows. Procurement-style intake forms with categorical fields ("contract type: SaaS / Services / Reseller"). Risk scoring based on vendor profile. A repository structured around vendor relationships and renewal cycles.
None of that maps cleanly to a solo attorney's work. A solo attorney isn't running procurement. They're running an engagement. The work they do is client work — for a client, on behalf of a client, billed to the client. The vendor-procurement metaphor at the heart of legacy CLM is a structural mismatch.
An engagement is the basic unit of outside counsel work. It groups everything that happens for one client into a coherent shape: the documents, the time, the correspondence, the deliverables, the billing. When a new piece of work comes in for the same client, it belongs to the same engagement (or a new one) — not to a fresh, unrelated record.
Legacy CLM doesn't have this concept. The closest analog is "deal," which carries the wrong implication (the platform is the deal's owner, the deal is the unit of revenue). Engagements aren't deals. An engagement might involve zero outgoing contracts and a dozen incoming counterparty papers. The shape is different.
This isn't just a labeling problem. It's a data-model problem. When the platform doesn't natively model engagements, you can't track time against them, you can't generate client-specific context, you can't run per-engagement summaries. You're back to a spreadsheet plus a folder.
For a solo attorney, billable time is the product. The thing that converts effort to revenue is the time captured against a client's work. Most legacy CLM platforms have no concept of billable time at all. Time tracking is an entirely separate tool (PracticePanther, Clio, etc.) that lives in a different surface and doesn't know anything about the document the attorney is currently working on.
The cost of this is enormous. Attorneys reconstruct their billable day from memory at the end of the week. Memory loses 30-40% of the actual work. The dark interstitial time — answering a client question on Slack, reviewing a comment, making a small fix — evaporates because there's no auto-capture and no convenient surface to log it.
A contract platform built for outside counsel has to start time-tracking from the editor. Every minute the attorney is in the document, on that client's matter, is billable work attributable to that client. This isn't a bolt-on. It's a primary surface.
Generic AI on contracts gives generic answers. For an outside counsel attorney working across multiple clients with different entity types, governing laws, and risk profiles, generic isn't useful. The same indemnification clause means different things for a Delaware C-Corp doing SaaS than for a California LLC doing healthcare services. The AI has to know which client it's working for.
Legacy CLM doesn't carry this context because it was never built around clients-with-context. It was built around vendors-with-categorization. The system knows "this is an MSA" but not "this is an MSA being drafted on behalf of a New York LLC with custom playbook deviations on liability and Delaware-mandated governing-law clauses."
For an outside counsel platform, every AI analysis has to be anchored to per-client context. Entity type, state of incorporation, governing-law override, playbook deviations specific to that client. Without this, the AI is generic, and generic isn't worth paying for.
Legacy CLM assumes you're sending paper out. You author from a template, you maintain the master version, you control the flow. That's the procurement model: the buyer drafts, the vendor accepts or pushes back.
Outside counsel work runs the other way. Most of the time, the counterparty's paper is the starting point. The client sends you the MSA they got from their counterparty and asks you to review it. The vast majority of your senior attorney time goes into redlining work product you didn't draft.
Legacy CLM has retrofit-grade support for counterparty paper review. It's treated as an exception path: upload the foreign document, do a one-time review, maybe convert it into a templatized version, file the executed copy. The platform doesn't expect counterparty paper to be the steady-state input — but for outside counsel, it is.
A platform built for outside counsel treats counterparty paper as the default. Every tracked change parsed individually. Risk-graded against your playbook. Suggested counter-language anchored to the cited clause. The platform expects the .docx redline as the most common file dropped into it, not the exception.
Legacy CLM client portals assume one user per client. The "external user" record is keyed on email. The whole organizational reality of the client — the contracts associate plus the deal owner plus the GC plus the procurement lead — gets compressed into whoever the first invited email belonged to.
For outside counsel, this falls apart on the first real engagement. The deal owner needs to send a question. The GC needs to approve. The contracts associate needs to upload a new draft. None of them are the original invited contact. The portal becomes a forwarding service.
A real outside counsel portal supports multiple users per client. Each gets their own login. Each can act independently. The attorney sees a unified timeline of who-said-what without having to ask "which of the four people at the client is currently driving this."
The pure TAM math explains a lot. The legacy CLM vendors built their products for the most lucrative segment they could identify: large in-house legal departments at Fortune 500 companies, where the deal size on each customer is six or seven figures and the procurement workflow generalizes across thousands of similar buyers.
Solo attorneys and small firms are a different shape. The deal sizes are smaller. The workflows are more varied. The buyer has less budget. The legacy vendors built for the easier money and let the other segment go unserved.
What this produced was a generation of attorneys at solo and small firms using a combination of Word, Outlook, Google Drive, a basic timekeeping tool, and a billing system, with no integration between any of them. Every contract review still happened in Word. Every client interaction still happened in email. The expensive CLM platforms in the market weren't worth the cost-benefit math to most of them.
The product gap is the opportunity. Outside counsel doesn't need a stripped-down version of legacy CLM. It needs a different platform entirely — one built around the engagement, the client portal, the billable hour, and the counterparty paper. Same problem domain, different shape, different software.
See what a contract platform looks like when it's actually fitted to outside counsel work.
Attorney-built · For solo and small firms · 14-day free trial