Legal AI: build vs buy
Most firms should buy. The exception is narrow, and knowing which side you are on saves a year.
The verdict
Buy legal AI for any workflow your firm performs the same way as every other firm, and build only where the workflow is your actual differentiator or where you are selling the product itself.
Legal research, practice management, e-discovery and contract review are solved categories with incumbents who have spent a decade on them. Harvey lists more than 70 AmLaw 100 firms and carries SOC 2 Type II, ISO 27001 and ISO 42001. You will not out-build that, and you should not try.
The build case survives in two situations. A firm whose intake, matching or matter routing is how it actually competes cannot buy that, because a product sold to everyone makes everyone the same. And a legaltech company has no buy option at all: the product is the thing being built.
Where each option wins
Dimensions that change the decision. Feature counts do not.
| Dimension | Buying a legal AI product | Building your own |
|---|---|---|
| Time to first value | Weeks. A pilot runs on your documents almost immediately. | Long enough that the pilot must be worth waiting for. Discovery comes before any estimate. |
| Legal research quality | Grounded in a licensed corpus you cannot get. Lexis and Westlaw content is licensed, not open. | Weak unless the firm already licenses a corpus. Never index Westlaw or Lexis content into your own store. |
| Security review by clients | Already answered. The vendor holds the certifications and the questionnaire responses. | Yours to answer. A build inherits your security posture, which is what a firm's questionnaire is actually asking about. |
| Ethical walls and matter scoping | Depends on the vendor honouring your DMS permissions. Ask before signing. | Enforced at query time by design, because you own the retrieval path. |
| Fit to an unusual workflow | Configuration only. If your process is unusual, you change the process. | Exact. This is the whole reason to build and the only one that holds up. |
| Who maintains it in year three | The vendor. Regulations move and their roadmap absorbs it. | Someone must own it. California requires re-assessment when models change, and that is recurring work. |
| Selling it to other firms | Not possible. You are a customer. | The only path. A legaltech product has no buy option. |
- Name itOne workflow, not a category
- AskIs it how you compete?
- PilotYour documents, not the demo set
- Read termsTraining, retention, subprocessors
- DecideBuy, build, or join the two
Most firms skip the pilot step and decide from a demo. A vendor demo runs on the vendor's own corpus, which is the one place the tool never disappoints.
Not sure which side you are on?
Scoping calls are free. Where we have to go into an existing codebase first, we run a paid two-week diagnostic, and you keep the findings whether or not you build with us.
Buying
Where buying wins
- Research grounded in licensed primary law, which no custom build can reproduce legally.
- The security questionnaire is already answered, which is what actually stalls legal software deals.
- Regulatory change is the vendor's problem, and the rules here move fast.
- You find out in a month whether the workflow helps anyone.
What you give up
- Independent measurement has been unkind. Stanford researchers found Lexis+ AI and Ask Practical Law AI gave incorrect information more than 17% of the time, and Westlaw AI-Assisted Research more than 34%, across 200-plus queries.
- Vendors publish badges rather than accuracy figures. Harvey's own page named no no-training guarantee when we read it.
- Configuration ends where your process is genuinely different, and then the process bends.
- Your data lives in someone else's boundary, and ABA Opinion 512 makes vetting that boundary your ethical duty, not theirs.
Building
Where building wins
- The retrieval path is yours, so ethical walls run when the query runs rather than filtering results after the fact.
- You can prove which endpoint saw which matter's data, which is the question Heppner turned into evidence.
- A legaltech founder gets a product to sell instead of a subscription to pay.
- Approval gates sit where California's guidance requires them, because you decided where they go.
What it costs you
- You inherit the security review. The certifications a client firm asks about attach to your organisation, so plan for who answers the questionnaire.
- Someone owns it after launch. That is an ongoing commitment, not a project line.
- Court deadline calculation and trust accounting should not be built with AI at all, so a build does not help there.
- Lexpair is the legal platform we run, on the intake and matching side. A build inside a document system inherits the firm's matter-level security, which is what the questionnaire is really asking about.
Which side are you on?
Four questions about your situation, not your preference.
Do you sell legal software, or use it?
Is the workflow you want to improve how you win business?
What is the task at its core?
Who answers a client's security questionnaire about it?
Every outcome
- Buy, and stop reading
- Your workflow is the standard one and the incumbents have spent years on it. Run a pilot on your own documents, insist on written no-training terms, and ask how the tool honours your DMS permissions before you sign.
- Build, because the product is the point
- A legaltech company has no buy option, and a firm whose intake or matching is its edge cannot buy that either. Expect the firm's ethical duties to arrive as your product requirements.
- Buy the tool, build the joins
- The common answer. Keep the incumbent for research or practice management, and build the integration, the intake and the reporting that nobody sells because it is specific to you.
- Neither yet, because this is a rules problem
- Deadline calculation and trust accounting need deterministic engines with versioned rules and hard invariants. A model that computes dates will be confidently wrong on holiday and count-backwards rules. Fix the plumbing first.
Rules that settle most cases
Apply these in order. The first one that matches usually decides it.
- 01Buy if a vendor's answer is 80% right and the missing 20% is preference rather than competitive advantage.
- 02Build if you are selling the software. There is no other option, and the ethics rules become your specification.
- 03Build the integration layer and buy the tools when your problem is that four systems hold four versions of a matter's status.
- 04Build neither if the task is deadline calculation or trust accounting. Both need deterministic rules and hard invariants, and a probabilistic system near a client ledger is a commingling bug waiting for a batch job.
- 05Pilot before you decide, on your own documents. Vendor demos run on the vendor's corpus, which is the one place their tool never disappoints.
Before you commit
01Can we buy a tool and build around it?
Yes, and it is the most common right answer. Firms keep Clio or a research product and build the intake, the routing and the reporting on top. Watch the rate limits when you do: Clio Manage documents 50 requests per minute during peak hours, so any sync has to be queued, incremental and resumable rather than a screen that fans out calls per row.
02Does buying protect us from the ethics exposure?
It moves the work, not the duty. ABA Formal Opinion 512 makes the firm responsible for vetting a vendor's reliability, security and breach practices, and California's 2026 guidance says reasonable efforts require more than reliance on generalized marketing assurances. You still have to read the terms.
03Our data is in iManage. Does that change the answer?
It raises the cost of both paths and pushes the schedule risk earlier. iManage's developer documentation is not publicly reachable, so nobody can scope that integration honestly before you have access. Make credentials a precondition rather than an assumption, whichever way you go.
04What breaks a build in year two?
Nobody owning it. Models change, the guidance changes with them, and California's guidance ties the level of oversight to the level of autonomy the system has. A build with no maintenance owner drifts out of compliance quietly, which is worse than failing loudly.
Related reading
- Does sending client data to an LLM waive privilege? →The February 2026 ruling that made vendor terms into evidence.
- Work product doctrine →Why direction of counsel belongs in your data model.
- Build vs buy software →The same question without the legal-sector constraints.
- Legal software development →What we have shipped in the sector, and what we have not.
