Build when the workflow is specific to your firm and repeats. Buy when the problem is universal and regulated. That line used to sit far to the buy side because writing software meant hiring a developer. AI moved it, and most law firms have not updated their thinking.
Here is what actually changed. Two years ago, a custom internal tool meant a developer at $100 to $200 an hour, a scope document, and a $10,000 minimum before anything worked. Nobody with a busy practice signs up for that to fix a reporting annoyance. So you bought whatever SaaS was closest and lived with the 60% fit.
Now you describe the tool in English and Claude Code writes it, runs it, and debugs it while you watch. I am not a programmer. I own 10 law firms and I have built a live KPI dashboard that pulls sign-ups across all of them, a document review system that reads lemon law files and flags what is missing, a demand letter generator, and an intake scoring tool. None of it required a developer. The build side of the ledger got much cheaper. SaaS pricing did not move at all.
What you should always buy
Some categories are not close calls. Do not build these:
Trust accounting and anything touching IOLTA compliance. E-signature with legal validity. Your practice management system of record. Payment processing. Anything with a regulatory certification requirement. Email and calendar.
The reason is the same in every case: the compliance and liability burden is the product. You are not paying Clio for a database. You are paying for the fact that when your trust ledger gets audited, someone else already solved reconciliation and three-way matching correctly and has been sued over it. That is worth every dollar, and rebuilding it to save a subscription is the dumbest possible trade.
What you should probably build
Internal dashboards and reporting. Checklist and QA tools specific to your practice area. Document generators for the documents your firm writes over and over. Intake scoring against your own criteria. Client status pages.
And the big one: any tool where you are paying full price, using maybe 20% of the features, and it still does not fit how your firm actually works. That gap is not going to close. The vendor is building for a thousand firms, not yours.
The decision table
| Factor | Build | Buy |
|---|---|---|
| Touches client money or compliance | Never | Always |
| Workflow is unique to your firm | Yes, this is the whole case for building | No, if everyone does it the same way |
| Repeats weekly or more | Yes, repetition is what pays back the build | Rarely, one-off needs are not worth owning |
| SaaS cost under $2,000/month | Worth a build experiment | Only if the fit is genuinely good |
| Catastrophic if it goes down | No, start elsewhere | Yes, buy the support contract |
The honest cost of building
This is where most articles on this topic turn into a sales pitch. Here is the other side.
You own maintenance forever. When the API you pull from changes, nobody emails you a migration guide. You own the security posture, which means you are the one deciding what gets encrypted and who can log in. There is no vendor to call at 2am, because you are the vendor. And version one always takes longer than you think, usually by a factor of two.
Which is why you start with internal tools where downtime is annoying instead of catastrophic. A dashboard that breaks on a Tuesday costs you a morning. A client-facing intake form that breaks costs you cases. Never make your first build something client-facing that handles sensitive data. Earn that.
The $2,000 rule
Here is the heuristic I use. Any tool under roughly $2,000 a month that does not quite fit is worth a build experiment. A weekend of building beats a year of paying for the wrong fit, and at that price point the vendor is usually solving something you could describe in two paragraphs.
Above $2,000 a month, the tool is usually solving something genuinely hard: integrations you do not want to own, compliance work, a data set you cannot recreate. Pay for it.
The number is not magic. Adjust it to your firm’s revenue. The logic is what matters: below some threshold, the subscription is buying convenience you can now generate yourself.
How to run your first build
- Pick an internal tool. Something you or your staff touch weekly that annoys you. Reporting is the usual first one.
- Write down exactly what it should do in plain English. Inputs, outputs, who uses it. One page, not a spec document.
- Build it in an afternoon with Claude Code. Describe the page, run it, tell it what is wrong, repeat.
- Use it for two weeks. Real work, real data, your actual staff.
- Decide: keep it, extend it, or throw it away.
Step five is the part people miss. Throwing it away costs you a weekend. Throwing away a SaaS contract costs you the remaining eleven months. That asymmetry is the whole argument.
Why this compounds
Every tool you build is one you own outright, do not pay for monthly, and can change the day your process changes. That last part is worth more than the savings.
When my lemon law firm changed how we score intake leads, the change took an afternoon. If that logic had lived inside a vendor’s product, it would have been a feature request, a roadmap conversation, and probably a no. Firms that build move at the speed of their own decisions. My document generator and document review system have both been rewritten since launch because the practice changed. That is normal, and it is only possible because I own them.
Pull up your last credit card statement and list every software subscription the firm pays for. Circle the ones under $2,000 a month that nobody loves. Pick the one that annoys you most and rebuild it this weekend.