I run this gauntlet too. A newsletter, podcast, consulting. Plugins to build, training to deliver, operations to improve across my businesses. This is what I do for a living and its still a lot to learn this stuff, teach it, and build with it. My job is to cut through the noise so you can stay on the foundations that compound. This piece is one of those cuts. I do all my work inside coding agents now. Claude Code, Codex, Open Code, etc. This works for marketing, legal, sales, coding and more. Take my ideas, apply them to your workflow. Master these six and your skills compound.

Harness | Memory | Plugins | Subagents | Voice | Verification

Subscribe now

How most builders handle it

Two default moves. The first is the demo chase: install whatever launched this week, try it once, never come back. The second is the freeze: wait six months until the noise dies down, by which point the people who started earlier are two compounding cycles ahead. Both leave you in the same place. Outside the work, watching.

Why it breaks

The problem is not tool selection. It is that almost no one has the foundations underneath. You can install forty plugins and still re-type your brief every session, lose your memory between conversations, watch a model drift off-task on a vague request, and accept its first answer because you have no way to check it. The tools are not the leverage. The harness, memory, and discipline around them are what give you the advantage.

A different approach

I stopped chasing features two years ago. I picked six foundations and rebuilt them every time something changed. New model, new harness pattern, new plugin format. I update the six, not the surface. The six are the part that compound. Anything on top is interchangeable.

Here is the six pieces I use in my own stack that have helped me, help you. Harness, Memory, Plugins, Subagents, Atomic Scope, and a Verification loop.

1. Good harness

The harness is the contract you give the model before any task. It tells the model what kind of work this is, what is in scope, what is out of scope, what "done" looks like, what to do when blocked, and what to never touch.

For me, the harness lives in two paired files at the root of every repo: `CLAUDE.md` for when I am working in Claude Code, and `AGENTS.md` for when I am working in Codex or any other agent that reads the AGENTS convention. My agent starter pack writes the same contract to both, because the tool of the month should never break the workflow. The contract is the same. The reader changes.

The detail that took me longest to get right: both files should be short. 200 lines at most. The job of `CLAUDE.md` and `AGENTS.md` is not to hold every fact about the project. The job is to define the startup contract and point at the documents that actually carry the detail. Boundaries first. Code map second. Commands third. "Ask first" and "never do" lists at the bottom. Everything else lives in `.agent/PLAN.md`, `.agent/HANDOFF.md`, `.agent/LEARNINGS.md`, `docs/`, or wherever else the project keeps depth, and the model loads those only when the request triggers them.

That pointer-driven structure is what keeps the token bill honest and the model focused. Every paragraph you stuff into the startup contract is a tax on every single session, whether or not that session needs the information. Most sessions do not. Move depth out of the contract and into the documents it points to, and the model reads exactly what it needs and nothing more. The starter pack has more of these small moves baked in.

The mistake most people make is treating `CLAUDE.md` and `AGENTS.md` like documentation: long, polite descriptions of the project. That is not what they are. They are behavior specs. Short. Imperative. Pointer-driven. If your harness reads like a README, rewrite it as a contract.

2. Good memory

Memory is the state the model can read across sessions. It is not what the vendor stores inside a chat history. It is what you keep in files, in the same repo as the work, under your control.

My memory layer is plain markdown. Each repo has `.claude/history.md` for session summaries: date, files changed, key decisions, current state, next steps. Each repo has `.agent/LEARNINGS.md` for durable patterns the model should apply next time. Global memory lives under `~/.claude/projects/<repo>/memory/` with one file per fact, indexed in a `MEMORY.md` table of contents. The model reads these on startup when triggered by the request. The model writes to them when it learns something worth keeping.

You can do this manually at the end of your session, or have the coding agent add key information automatically. Either way, when you come back to it later, you aren’t starting from zero or forcing the agent to review everything.

Two things matter about this setup. First, the format is greppable. I can search across every session I have ever run on a project and find the moment I made a decision. Second, the format is portable. When a new model lands, when a new harness ships, when I switch tools entirely, the memory comes with me. None of it is locked inside a vendor's storage.

Closed memory inside a vendor product is rented ground. The day the vendor changes pricing, deprecates a feature, or shifts model access, your accumulated state goes with it. You start over. Builders do not start over. Builders keep their memory in files they control.

3. Good plugins

Plugins are the small, named, repeatable units of work a model can run without you re-explaining the instructions. A skill that knows how to draft a Substack article in your voice. A skill that knows how to build out a deposition witness kit. A skill that knows how to run your matter intake system. Each plugin is a folder of markdown and config that the model loads on demand.

The wrong question is "which plugins should I install." The right question is "which tasks do I do weekly that I want a model to never forget how to do." Answer that, and the plugins almost write themselves.

For my coding work, the stack is small. My own PossibLaw-Plugins for content drafting, design grilling, and triage. The `superpowers` plugin from Anthropic for TDD discipline, brainstorming, debugging, and the cross-cutting workflows I want enforced regardless of project. A handful of single-purpose plugins for specific clients. Five total, give or take. Not forty.

The other mistake to avoid is installing a plugin and never editing it. Plugins are scaffolds, not finished products. The first thing I do with any plugin I install is read the SKILL files, find the one place it does not match how I actually work, and patch it. That is the difference between a consumer of plugins and an author of them.

4. Agents to manage context

A subagent is a separate model run inside a larger task. Its own context window, its own tools, its own system prompt, its own short brief from the main model. It does one thing, returns a summary, and exits. The main model never sees the raw material the subagent read.

This sounds like a small optimization. It is the difference between a session that holds together and a session that decays. One model carrying every concern is how drift happens. Research blurs into drafting, drafting blurs into review, the context window fills up with old tool output, the model starts compressing earlier turns, and forty turns in the thread is lost. You feel it as the model getting "dumber." It is not. The context is exhausted.

The fix is delegation. I use subagents constantly. A research agent reads a long external document and returns a one-page brief. A code-exploration agent greps through a repo for every reference to a symbol and returns a list of file paths and line numbers. An editorial reviewer reads a draft against the brand rubric and returns severity-rated findings. A test-runner agent runs the test suite, parses the failures, and reports which ones are real versus flaky. Each one gets a clean context, does its job, and disappears. The main model stays sharp because it never had to hold the full source material itself.

Parallel agents are the second move worth learning. When two pieces of work are independent, run them at the same time in different subagents. I cut a research-heavy task from twenty minutes to three this way last week. Independent work in parallel is free latency reduction.

Share PossibLaw

5. The voice unlock

The hidden friction in large projects is the endless typing and it is the reason most people abandon good context engineering and prompt hygiene. The fix is to take typing out of the bottleneck.

Voice is the biggest unlock I have added to my workflow in the last year. I dictate almost every prompt during a working session. The built-in macOS dictation will get you started. The tool I actually use is Wispr Flow, which transcribes faster and more accurately and adds the move that changes the math: snippets. A snippet is a short trigger that expands into a reusable block of text. I have snippets for the prompts I run constantly. A few words paste in the brand voice file. Another loads the editorial rubric. Another pastes the link to the project brief I always reference. Another fires off "treat this as TDD, write the failing test first, then implement, then verify."

Every time I notice myself typing or speaking the same context twice, I make it a snippet. After a month, the slow part of the loop is not me anymore. It is the model. That is the right place for the bottleneck to live.

6. A verification loop

This is the one most vibe coders skip, and it is the one that decides whether the other five compound errors or compound leverage.

Verification is how you know it worked. A test. An eval. A rubric. A known-good input run through the new system to see if the output matches what it should. A second model checking the first model's work. A diff against the previous version. A human spot-check on the riskiest output. The form varies. The discipline is the same: you do not trust the output until you have checked it.

For legal work the stakes make this obvious. A confidently wrong citation is a Rule 11 problem, not a productivity gain. A confidently wrong privilege call is a malpractice problem. A confidently wrong redline that drops a key carveout is a deal problem. Everything an AI produces in a legal workflow needs a verification step before it goes anywhere a partner, a client, or a regulator can see it.

For everyone else the stakes are still real. Code that looks fine and ships without tests breaks in production two weeks later, usually at 11 p.m. on a Friday. Content that looks fine and ships without an editorial pass goes out with the brand voice slightly off and a fact slightly wrong, and you do not catch it until the third reply on LinkedIn. "I checked" is the discipline that separates builders from passengers.

The cheapest verification loop is a one-page rubric per workflow. For my Substack drafting, the rubric is the four-question self-edit checklist plus the brand voice file. For my plugin work, the rubric is "did the validator pass, and does the README example actually run." For my client work, the rubric is matter-specific and lives in the harness. None of these are fancy. All of them get run every time.

The ReCode

The question is not which new tool to learn this week. It is whether you have the foundations that let any tool compound.

Pick one of the six. Get it right by Friday. Do the next one the week after. By the time the next AI announcement lands, you will read it as a builder reading a spec, not as a tourist reading a brochure.

That is what I am here for. Cutting through the noise so you can build is my job. This newsletter, the podcast, the training, the plugins, all of it points at the same outcome: foundations that compound, week after week, regardless of what ships next. I can’t wait to see what you go build.

Subscribe now

What you're actually building

A Claude Code plugin is a directory with one required file: a manifest at `.claude-plugin/plugin.json`. Everything else (skills, agents, hooks, MCP servers) is optional. You add only what you need.

The four pieces you'll meet first.

Manifest (`.claude-plugin/plugin.json`). Name, version, description. Three fields. That's the floor.

Skills (`skills/<name>/SKILL.md`). A markdown file with YAML frontmatter that gives the model instructions for a specific task. Claude decides to use it based on the description (model-invoked) or you trigger it explicitly with `/plugin-name:skill-name`.

Agents (`agents/<name>.md`). A packaged subagent with its own system prompt, tools, and execution context. Use these when you want autonomous work done inside a larger task.

Hooks (`hooks/hooks.json`). Event handlers that fire before or after tool use. Powerful. Easy to misuse. Skip on your first build.

The official reference lives at code.claude.com/docs/en/plugins. Treat it as your source of truth. Everything below is orientation; that page is the spec.

The eight steps

1. Pick a workflow you do every week. Not a vague aspiration. A specific task. "Every time I draft a client memo, I run the same five checks: facts straight, citations Bluebooked, privilege-marked, deadlines flagged, distribution list verified." That's a plugin. So is "every time I open a new matter, I walk the same intake interrogation." Concrete is the bar.

2. Read one plugin before you write one. Install one from a marketplace and read its files. Mine is at github.com/PossibLaw/PossibLaw-Plugins if you want a legal-specific example. `possiblaw-vibe` is a design-grill plugin built on Matt Pocock's grill-me pattern. Reading working code shortcuts the abstraction.

3. Scaffold the directory.

my-plugin/
  .claude-plugin/
    plugin.json
  skills/
    my-workflow/
      SKILL.md

Warning from the docs: do not nest `skills/`, `agents/`, or `hooks/` inside `.claude-plugin/`. Only `plugin.json` lives there.

4. Write the manifest.

{
  "name": "my-plugin",
  "description": "What this does in one sentence.",
  "version": "1.0.0"
}

Version it from day one. Semver. You will ship updates.

5. Write the skill. Open `skills/my-workflow/SKILL.md`. The frontmatter:

---
description: Runs the five-check memo review (facts, citations, privilege, deadlines, distribution).
---

Below the frontmatter, write the instructions the way you'd brief a new associate on day one. Explicit. Specific. With examples. If the skill should ask the user something before acting, say so. If it should refuse to write anything until a condition is met, say so.

One skill, one job. Don't bundle memo review with contract redlining with intake triage. Three skills, three files.

6. Test locally.

claude --plugin-dir ./my-plugin

Then run `/my-plugin:my-workflow` inside the session. Edit, save, run `/reload-plugins`, try again. Each pass tightens the prompt.

7. Add an agent only if you need one. Skills handle "do this specific task" cases. Agents handle "go run this autonomous loop and report back." If you find yourself wanting Claude to research, then test, then report, that's agent territory. Same pattern: markdown file in `agents/`, frontmatter declares description and tools, the body is the system prompt.

8. Publish via a marketplace. Create a separate repo for your marketplace (or reuse one you have). Add a `.claude-plugin/marketplace.json` listing your plugin. Then anyone (your team, your colleagues, a client) can install with:

/plugin marketplace add yourorg/your-marketplace
/plugin install my-plugin@your-marketplace

That's the distribution loop. From there it's iteration: use it in a real session, see what breaks, refine, ship a new version.

The reframe

The moment you commit your first `plugin.json` to a repo, you've crossed a line. You stopped being a tool consumer. You became a tool author.

That shift compounds. The next workflow you spot, you'll see it as a plugin candidate, not a recurring annoyance. The next time Anthropic ships something new, you'll fork it and shape it instead of installing it raw. Your team starts running your patterns instead of someone else's.

That's what builder means in practice. Not "I write code." It means the systems you rely on are the ones you shaped.

Start with one workflow. Ship a plugin this week.

Start, then grow. Will did the start in public. The reminder is for the rest of us.

The discourse missed both the gratitude and the lesson because most legal professionals are watching this AI moment as consumers. They pick a vendor or they pick a critique. Either way they stay passengers in the most consequential shift the profession will see in our careers. Mike OSS is the surface symptom: two tribes arguing about what the repo proves, and almost nobody building anything in response.

The default move is to outsource the read. The anti-vendor camp says Harvey and Legora are overpriced wrappers and Will just proved it. The pro-vendor camp says the YC engineers are right, this is vibe-coded, two commits long, and you should pay Harvey. Pick a tribe, post the take, move on.

Neither tribe of traditional lawyers is reading the code, and neither is teaching. You stay outside the work, dependent on someone else’s framing for what good looks like. Nobody opened the repo. I did.
So I thought it would be helpful for those learning to build, to get a feel for what I saw.

Subscribe now

What’s good

A real scaffold. Next.js on the App Router. Express and TypeScript backend. Supabase for auth and Postgres. S3-compatible object storage. LibreOffice, mammoth, and pdfjs for ingestion across DOCX and PDF. fast-diff for redline-style comparison. Anthropic SDK and Google’s GenAI SDK both wired in, so the model layer is vendor-flexible from day one. AGPL-3.0 license, a deliberate signal that this is a contribution to the commons, not a venture in disguise. The hard, boring parts of legal software are here: document parsing across formats, auth, storage, file uploads, a working frontend, a redline pipeline. Will did real work.

What needs work

Will’s own issue tracker has the headlines, and the schema confirms them.

Row-level security is enabled on exactly one table out of seventeen. Every project, document, chat, workflow, and tabular review table has RLS off. The backend uses Supabase’s service-role key, which bypasses RLS by design, so all isolation lives in application code with no database safety net. One missed auth check anywhere and a tenant reads another tenant’s documents.

A filed authorization bypass on `/chat/create` accepts a caller-supplied `project_id` and creates a chat without verifying access. Cross-tenant injection is one curl command away.

A plaintext log file, `claude-raw-stream.log`, captures every Claude streaming event. Full user messages, full document context, full assistant responses, written to the repo root with no rotation and no environment gate. On a legal platform, that single file is GDPR and SRA exposure in one artifact.

The download-token signing logic falls back to a hardcoded `”dev-secret”` when the env var is missing, with no startup error. Anyone can forge download URLs against a misconfigured deployment.

No tests. No evals. No CI. No Dockerfile. No backend linter.

Closing those gaps is real work: RLS done right, route-level auth, log and secret hygiene, evals tied to your matter types, retrieval over firm content, multi-tenant ops, security review, support. That is most of what Harvey and Legora charge you for, and it deserves real respect. Hard things take skill and discipline, and the teams doing them at scale are doing the work.

The signal

Both things are true at once. Will’s start has value because someone shipped it. The vendors’ polish has value because someone has to build it. The gap between them is the invitation.

Building has always been good. The new part is that it does not have to be a developer doing it anymore. Lawyers and legal professionals with the right skills can ship architecture into the commons the way Will did, build on top of what others ship, and make decisions across vendor and open source with a builder’s eye instead of a fan’s. “Build” is now a real third option alongside “buy” and “wait,” and the people who choose it are the people who shape what comes next.

How to go look without hurting yourself

The cheapest read costs you nothing. Open the repo in your browser. Look at `backend/migrations/000_one_shot_schema.sql` and notice that `enable row level security` appears exactly once across seventeen tables. Open the issues tab and read the four security tickets in order. Twenty minutes, no install, no clone. You will already understand more about the legal-AI build problem than most of the partners on your last innovation call.

If that makes you curious enough to actually run it, treat it the way you would treat a matter under an NDA. This is how you safely learn and test. The goal is not “get it running as fast as possible.” The goal is: read first, sandbox second, do not deploy.

The safest mindset

Scroll down and get a step by step tutorial on how to do this safely. Remember, Cloning the repo is not the risky part. The risky part is the moment you give unfamiliar code secrets, documents, network access, or a production environment. Read it first. Run it locally. Use fake data. Use a capped throwaway API key. Keep it away from your inbox, shared drives, and client files. Only after the security questions are answered should you consider letting it touch anything real.

Critics react. Builders read the code. Will Chen built Mike OSS. The rest of us get to respond as builders, not as fans, by reading what he shipped and starting our own or forking his and building something new. Go try. Go build.

First run checklist

Before starting the app, ask:

1. Does it require secrets?

2. Does it ask for access to real documents?

3. Does it upload files anywhere?

4. Does it open a public port?

5. Does it have unresolved security issues?

6. Does it have install scripts that run automatically?

7. Does it require admin privileges?

8. Does it connect to third-party services?

A safe first run looks like this:

Local machine only.
Synthetic files only.
Fresh API key only.
Low spend cap.
No inbox.
No shared drive.
No production data.
No public tunnel.
No deployment.

Click-by-click: clone the repo with GitHub Desktop

This is the most beginner-friendly path.

Step 1: Open the repo on GitHub

Go to the GitHub page for the project.

Before clicking anything, skim:

• The README

• Open issues

• Recent commits

• Install instructions

• Any mention of API keys, local files, Gmail, Google Drive, Dropbox, Notion, SharePoint, Slack, or document access

Do not run anything yet.

Step 2: Click Code

On the main repo page, look above the file list and click the green or gray Code button.

Step 3: Click Open with GitHub Desktop

In the dropdown, click Open with GitHub Desktop. GitHub documents this as the path for cloning and opening a repo directly in GitHub Desktop. (GitHub Docs)

Step 4: Choose a safe local folder

When GitHub Desktop asks where to save it, choose a local folder like:

~/Code/sandbox/repo-name

Avoid putting it inside:

~/Documents
~/Desktop
~/Dropbox
~/Google Drive
~/OneDrive

The point is to keep the repo away from real client files, synced folders, and anything that could accidentally upload or expose data.

Step 5: Click Clone

Click Clone. At this point, you have copied the code to your laptop. You have not proven that it is safe to run.

Optional: clone with Terminal instead

For readers who prefer the command line:

Step 1: Click Code

On the repo page, click Code.

Step 2: Copy the HTTPS URL

Choose HTTPS, then copy the repo URL. GitHub supports HTTPS and SSH clone URLs; authentication differs depending on which one you choose. (GitHub Docs)

Step 3: Open Terminal

On a Mac, open Terminal.

Create a sandbox folder:

mkdir -p ~/Code/sandbox
cd ~/Code/sandbox

Step 4: Clone without submodules first

Paste the repo URL into this pattern:

git clone --recurse-submodules=no https://github.com/OWNER/REPO.git

Then enter the folder:

cd REPO

Do not run install commands yet.

What to read before running anything

Before npm install, pip install, docker compose up, or any “quickstart” command, inspect the project.

Look for:

README.md
SECURITY.md
.env.example
package.json
pyproject.toml
requirements.txt
Dockerfile
docker-compose.yml
Makefile
scripts/

Pay special attention to scripts that do things like:

curl ... | bash
sudo ...
chmod +x ...
rm -rf ...
open ports
upload files
connect to Gmail
connect to Drive
connect to Slack
read ~/Documents
read ~/.ssh
read ~/.config

For Node projects, inspect package.json scripts before installing:

cat package.json

For Python projects, inspect dependencies before installing:

cat requirements.txt
cat pyproject.toml

For Docker projects, inspect the container setup before running it:

cat Dockerfile
cat docker-compose.yml

Set up a throwaway API key

Use a fresh API key for this repo only. Do not reuse your production key.

For Anthropic, the Claude API has spend limits that set a maximum monthly cost an organization can incur, separate from rate limits. (Claude)

For Gemini, Google says the Gemini API supports monthly spend caps at the billing-account and project levels, though not for invoiced/offline accounts. (Google AI for Developers)

Recommended rule:

One repo = one fresh key = one low spend cap = delete it when done.

Use something like:

ANTHROPIC_API_KEY=your_throwaway_key

or:

GEMINI_API_KEY=your_throwaway_key

Put it in a local .env file only if the project expects that. Never paste keys into code. Never commit .env.

Before running anything, confirm .env is ignored:

cat .gitignore

If .env is not listed, add it before doing anything else:

echo ".env" >> .gitignore

Use fake data only

Create a small test folder:

mkdir synthetic-test-docs

Put in harmless fake files:

sample-contract.txt
sample-email.txt
sample-policy.txt
sample-invoice.txt

The contents should be obviously fake:

This is a synthetic test contract between ExampleCo and Demo LLC.
No real client, customer, employee, legal, medical, or financial data appears here.

Do not connect the repo to:

Your inbox
Your document management system
Google Drive
Dropbox
OneDrive
SharePoint
Notion
Slack
A client folder
A production database

Run it locally, not on a server

Do not deploy the app to Vercel, Render, Railway, Fly.io, AWS, GCP, Azure, or a public VPS just to “see what happens.”

Run it on your laptop.

Prefer local URLs like:

http://localhost:3000
http://127.0.0.1:8000

Avoid commands that expose your machine to the internet, such as:

ngrok
cloudflared tunnel
ssh -R

until you understand exactly what the app does.

CHAPTERS

00:00 Introduction to Matt Basile's Journey
03:32 Parenting and Entrepreneurial Mindset
06:19 The Importance of Travel in Shaping Perspectives
10:10 Transitioning from Software to Law
13:58 Navigating Change in the Legal Industry
18:12 Embracing Iteration and Learning from Failure
22:05 Building Naya: A Solution for Legal Challenges
27:49 The Shift to Full Stack Law Firms
32:13 Navigating Competition in Legal Tech
36:17 Curiosity and Learning in Legal Practice
42:15 Understanding Naya's Role in Legal Tech
46:18 Future Strategies for Naya and Legal Partnerships

Takeaways

• The only way to get good at legal AI is to stop reading and start trying. Curiosity and iteration beat credentials.

• LLMs are a programming language inside a software stack, not a feature you paste on top of a legacy workflow.

• Selling AI tools to law firms failed for a decade because clients buy outcomes, not productivity gains.

• Naya pivoted from selling to lawyers to selling to the mortgage lenders who actually stand to benefit from faster closings.

• The Management Services Organization model lets an AI-native firm scale legal capacity without traditional partnership drag.

• Clients are ready to cannibalize the billable hour; most partners five years from retirement are not.

• The right hire for a tech-first law firm is a builder who wants to sell the new model, not a lawyer who wants billable stability.

• Legal work product still has to be 100 percent right. The tools you build to get there can ship at 80 percent and iterate.

• Document automation has been viable technology for 10 years. The reason it did not stick is incentive structure, not capability.

• Enterprise systems that teams already work in every day are defensible in a way point AI tools are not.

👤 Guest Bio
Matthew Basile is the founder and CEO of Naya Software and Naya Law, based in the Greater Tampa Bay Area. He earned his JD at Fordham University School of Law, where he served on the Fordham Urban Law Journal, and practiced real estate law before leaving to build Naya full-time. Naya is an AI-powered enterprise platform for commercial real estate mortgage originations; its users have closed 1,319 transactions totaling $35.2 billion, running on Microsoft Azure with SOC 2 Type II certification. Matt writes the "Technology for Real Estate Transactions Newsletter" on LinkedIn, where he focuses on AI-native law firm design, Alternative Business Structure and Management Services Organization models, and real estate transaction technology. In his free time he is raising four boys, traveling with his family, and hiking and skiing with them whenever possible.

🔗 Connect With Matt
• LinkedIn: https://www.linkedin.com/in/matthewjbasile/
• Naya Software: https://www.nayasoftware.com

🔗 More From Salvador
PossibLaw: https://www.possiblaw.com
Full podcast library, essays, and tools for legal professionals who are done watching from the sidelines.
LinkedIn: https://www.linkedin.com/in/salvadorcarranza

No. Its a little more nuanced that, and yet, yes. Yes, I want you to vibe code a tool.

Builders across every industry buy software constantly. They pay for licenses. They pay for platforms. They stitch together off-the-shelf pieces without a second thought. What makes them builders isn't that they write every line of code. It's that they can read the architecture of what they're buying, argue with the vendor on the merits, and decide with their eyes open which layers to own and which to rent.

The point of becoming a builder isn't self-sufficiency. It's the ability to learn these new systems so you get to choose.

The problem: passive buyers in a market that rewards active ones

The legal market right now is a vendor carnival. Every week a new AI tool is pitched as the one that finally solves contract review, intake, due diligence, matter management, discovery. Partners and GCs are being asked to make procurement decisions on technology they cannot evaluate from the inside. So they default to what feels safe: wait, read an analyst report, trust the deck, buy what the peer firm bought. It's the expensive choice dressed as the safe one.

How most legal leaders solve it

Two default moves, and you've seen both.

First is vendor trust by proxy. The firm signs whatever the largest peer firm signed six months ago. The GC picks the platform with the most recognizable logos on the website. Nobody can tell you why the product works or where it breaks, but the procurement memo writes itself.

Second is the opposite, and it's what the GC at the conference was worried about. Somebody reads a post like this, decides they've been told to become engineers, and starts building from scratch because "that's what a builder does." A month later they have a half-finished intake form, a Zapier chain held together with sticky notes, and a growing conviction that this was all a mistake.

Both moves share a root cause. Neither person can read the architecture.

Why it breaks

A useful piece from Flank lays out what it actually takes to ship a production-grade legal AI agent end to end. Seven engineering layers sit under the hood: document ingestion, multi-model orchestration, legal logic encoding, human supervision, workflow integration, security and compliance, ongoing maintenance. Four to six engineers for twelve to eighteen months, then two or three permanently, before a single contract is processed.

For full-stack production legal AI at enterprise scale, I agree with where they land. Buy. The economics don't pencil out for anyone who isn't already running real engineering teams. But as is always the case, that's half the story and the half vendors like you to stare at.

The interesting half is that you can only agree or disagree with any of this on the merits if you can read the seven layers. The builder-minded lawyer says, "Ingestion and compliance I rent, legal logic encoding I keep in-house because it's my edge, supervision I design myself." The passive lawyer says, "The vendor told me it's a platform." One of those people makes a better decision every quarter for the next ten years.

A Tuesday afternoon in a GC's office

Here’s a story that every lawyer reading this will viscerally feel. It’s a little bit of lack of knowledge, a little bit of nobody gets fired for hiring IBM, and a little bit of fear. I’ve been in the room when this decision is being made more times than I can count, and it’s almost always the same.

A GC walks into her office Tuesday afternoon with three options on her desk for a contract intake system. A six-figure vendor with a polished demo and a great logo wall. A scrappier platform with better hooks. A “Frankenstein” form builder, workflow engine, and retrieval layer stitched together by a contractor. Six months earlier she’d have picked the first without reading past the executive summary. She’d have paid for seven layers and used three.

Same GC, different quarter. She reads up on what actually goes into shipping production legal AI and makes her team draw the seven layers on a whiteboard for each option.

The first owns all seven and charges accordingly. The second owns five and opens the other two to her team. The Frankenstein owns two well and leaves her exposed on security and maintenance. Her head of legal ops says: “We’ve been evaluating features. We should have been evaluating layers.” She buys the second.

On the procurement call she names which of the seven layers she’s actually paying for and which she plans to own herself. The vendor’s rep stops reading from the deck and starts answering real questions. The contract closes on terms her legal team understands and can leverage.

She doesn’t write a single line of code on this deal. But the only reason she can run that room is that the quarter before, she spent two weekends building a clause extractor on her own laptop, just to see what broke. That’s where the vocabulary came from.

Subscribe now

Building is the learning

That last detail is the whole point, and it's the part most lawyers miss when I tell them to operate like builders. I'm not telling you to build because building is an end in itself. I'm telling you to build because it is, by a wide margin, the fastest way to actually learn this stuff. You try something. It breaks. You find out why. You fix one thing. It breaks somewhere else. You learn what ingestion actually means the first time a scanned PDF comes in sideways. You learn what retrieval actually means the first time your model confidently cites a case that does not exist. The loop is the teacher.

Every serious study of how people actually learn points the same way. Freeman and colleagues' 2014 PNAS meta-analysis pooled 225 studies of active versus passive learning in undergraduate STEM classrooms. Students in traditional lectures were one and a half times more likely to fail. The setting is undergraduate biology, not senior legal, but the failure mode is identical: passive exposure to an unfamiliar system does not build a working model of that system. Deslauriers and colleagues followed up in 2019 with a result that should make every senior lawyer uncomfortable: students in active classrooms learned measurably more but felt they learned less than their passive-lecture peers. The passive stance feels more competent. It isn't.

The one I come back to most is Dell'Acqua and colleagues' 2023 study of 758 BCG consultants using GPT-4. Inside the model's frontier, AI users finished 12.2% more work, 25.1% faster, at 40% higher quality. Outside the frontier, the same users were nineteen points less likely to get the right answer. The difference between winners and losers wasn't raw intelligence. It was whether they interrogated the model or trusted it. The interrogators won. The trusters got confidently wrong answers at speed. "Interrogated the model" is just another way of saying layers already know, the socratic method. Interrogate like a builder by treating procurement like something to build with instead of something to buy from.

You do not get to architectural literacy by reading about it. You get there by breaking things and fixing them on a short loop. Pin that to the wall.

What being a builder actually means

You can read the seven layers. When a vendor rep says "our platform handles that end-to-end," you can ask which layer and hear the answer for what it is. Your build-versus-buy conversation stops being a gut call and starts being a portfolio decision: this layer we own because it's our edge, this one we rent because it's a commodity, this one we stitch because nothing off the shelf fits.

And here's the other half of the picture nobody in the vendor carnival wants you to notice. A lot of the tools lawyers actually need every day are not full-stack production systems. They are small, scoped, and local. A clause extractor that runs on your own laptop. A retrieval layer inside your firm's existing Microsoft or Google tenancy so nothing crosses a confidentiality line. A triage assistant running on a local model so privileged material never leaves the perimeter. The stack under these is mundane: a Python notebook or a Google Apps Script, an open-source embedding model, a form your team is already using, and an afternoon of pairing with the AI coding assistant your firm is already paying for. Two weekends of work, not twelve months. No engineering team. No £500K run rate. I've built some of these. Lawyers I work with have built more. They don't replace the big platforms. They're the reason you can tell when the big platforms are being oversold.

Being a builder doesn't mean you build everything. It means you can build the small thing when the small thing is the right answer, and you can read the architecture of the big thing when you have to buy it. That optionality is the entire point.

You don't have to build everything. You do have to have built something. Everything else follows.

These companies are not building tools. They are building operating systems. And every one of them wants to be the layer your firm can't turn off.

The pitch

Gabe Pereyra, Harvey's co-founder, published a piece last week called "Legal is Next." The thesis: Harvey has built an internal agent called Spectre that handles work autonomously, triggered not by humans but by the system itself. The implication: this architecture will soon run inside law firms. Artificial Lawyer called it a potential "law firm world model."

Pereyra frames it as liberation. Agents replace the base of the pyramid. Associates stop doing throughput work. Partners focus on judgment. The firm reorganizes around what he calls "a surplus of intelligence bottlenecked by judgment."

It's a good phrase. It's also a pitch from a company that grew from $100 million to $190 million in ARR in five months, now serves over 100,000 lawyers across 1,300 organizations, and needs to justify an $11 billion valuation to Sequoia, Andreessen Horowitz, and every other investor at the table.

What they're actually capturing

Here's what most legal teams miss about these platforms.

The obvious concern is data. Your documents, your research, your matter files. That matters, but it's not the real play. The real play is what Foundation Capital's Jaya Gupta calls "decision traces": the record of how your firm actually makes decisions.

When an agent handles contract review, it doesn't just process the document. It captures which clauses your team flags, what exceptions get approved, which risk thresholds trigger escalation, and how partners resolve edge cases. That reasoning, the institutional logic connecting data to action, was never treated as data before. Now it is. And whoever's platform captures it owns something far more valuable than your files.

Gupta's argument is direct: "SaaS incumbents can add AI to their data, but they can't capture what they never see." The companies sitting in the execution path, Harvey, Legora, whoever processes your actual work, see the full decision context. The inputs gathered. The policies evaluated. The exceptions granted. Every automated decision adds another trace to a graph that becomes harder to replicate and harder to leave.

These platforms capture how your firm thinks.

Subscribe now

Why "check your contract" is not a strategy

Most advice about vendor risk boils down to "negotiate better terms" or "read the contract carefully." That's not wrong. It's just insufficient. It's like telling someone to read the nutrition label while the food supply chain is being redesigned around them.

The structural issue isn't contract language. It's architectural. If your workflows, your decision patterns, and your institutional knowledge all live inside a vendor's system, your contract terms are a guardrail on a road you don't own.

And the platforms know it. Salesforce already restricted AI competitors' access to Slack data. Foundation Capital predicts more of the same: "more limits on API usage, more restrictive terms, and more integration hurdles." The access gets tighter, not looser, as the vendor's position strengthens.

Meanwhile, 69% of legal professionals now use generative AI tools at work, more than double from last year. But 54% of law firms offer no AI training and 43% have no AI governance policy. That's mass adoption without the architectural literacy to understand what's being adopted or what's being surrendered.

A real path forward

Here's to actually do. Not in theory. In practice, this quarter.

Build small tools that solve real problems now. You don't need to replace Harvey. You need to stop being helpless without it. A microsaas that automates your NDA intake, a small app that routes contract requests based on your own logic, a simple tool that formats your research memos the way your partners actually want them. These aren't products. They're proof that your firm can build its own workflow logic rather than renting someone else's. Every small build compounds your team's understanding of how software actually works. That understanding is what lets you evaluate vendors from a position of knowledge rather than dependence.

Make purchasing decisions architecturally, not feature-by-feature. Stop comparing AI vendors on what they can do and start evaluating them on how they connect to what you already own. The questions that matter: Does this tool work with my data where it already lives, or does it require me to move everything into its system? Can I pipe outputs from this tool into other tools via API, or does it only work inside its own walls? If I stop paying, what do I keep? Engineers call this evaluating "interoperability and portability." Legal teams should call it due diligence.

Treat your data as an API, not a filing cabinet. This is the mindset shift that changes everything. Your matter data, your contract corpus, your research memos, your decision history: this isn't static content sitting in folders. It's an asset that should be queryable by any system you authorize. When your data is structured and accessible via API, you can plug it into Harvey today, switch to Legora tomorrow, and build your own internal tool next quarter. When your data lives inside a vendor's proprietary format with no export path, you've handed over the keys. The firms that structure their data as a portable, machine-readable layer will have options. Everyone else will have a vendor they can't leave.

One giant caveat here. Anyone that has spent anytime inside a law firm or legal department knows that your data is not clean. Its all over the place, and often living inside some lawyer or legal ops professional’s brain. So to get the data API layer right, you have to go back to basics and start building data the right way.

Own your decision traces. This is the new frontier. If you're using an AI platform that captures how your firm makes decisions, you need to know where that record lives. Can you export it? Is it in a format you can use elsewhere? Or does it exist only inside the vendor's system, making your institutional logic their proprietary data? The firms that log their own decision patterns, even in simple internal systems, keep the one asset that's hardest to rebuild from scratch.

The real training deficit

Pereyra says "intelligence replaces hierarchy." Maybe. But intelligence supplied by a single vendor, trained on your data, priced at their discretion, and embedded so deeply that extraction would take years of re-engineering is not independence. It's a different kind of hierarchy with a different owner.

The vendors racing to $11 billion valuations are building something real. The technology works. I'm not arguing against using it. I'm arguing against using it blindly.

The teams that learn how software architecture works, how data flows, how APIs connect systems, and how vendor lock-in actually operates will make better decisions than the teams chasing the most impressive demo. That has always been true of infrastructure decisions. AI is not different.

The gap between the firms that understand these systems and the firms that just buy them widens every quarter. That's a compounding problem. And nobody is going to close it for you.

Share PossibLaw

I was a kid. My parents brought home an IBM, and there was no desktop, no icons, no mouse. Just C:\> and whatever you could figure out how to type after it. MS-DOS. A blinking line that either did what you told it or threw an error with zero explanation for why.

I didn’t know what an operating system was. I didn’t know what a command line was. I just knew that if I typed the right thing, something happened. And if I typed the wrong thing, I learned what not to type next time.

I played a game called Castle Adventure. Pure ASCII art on a monochrome screen. Rooms drawn out of block characters and line glyphs. Your character was a little clover symbol navigating corridors, and the monsters chasing you were smiley faces. Actual smiley faces. You typed commands like “GET SWORD” and “SHOW CROSS” to repel a vampire, and you moved room to room through gaps in the walls. There was no health bar, no save system that worked, no tutorial. If you died, you started over.

A 14-year-old kid named Kevin Bales wrote the whole thing in his mother’s basement in 1984. It shipped on floppy disks passed around through bulletin board systems. It was crude, it was frustrating, and something clicked in that moment that I’ve carried my entire career: the machine does what you tell it. The question is whether you know what to tell it.

That was the last time a computer felt fully open to me for a long time.

Subscribe now

The layers started stacking.

Windows arrived. Then the web. Then mobile. Each one made computers easier to use. Each one also made them harder to control.

This is the tradeoff nobody talks about. Every abstraction layer in computing exists to hide complexity from the user. GUIs hid the command line. Web apps hid the local file system. Mobile apps hid the web. And every time a layer got added, the people who built it decided what you could and couldn’t do. The menus, the buttons, the features, the workflows. All designed by someone else, for someone else’s idea of what you needed.

Joel Spolsky nailed it in 2002: all non-trivial abstractions are leaky. They save you time working, but they don’t save you time learning. And when they break, if you don’t understand what’s underneath, you’re stuck.

I watched this play out in legal in real time.

If you practiced law in the last 20 years, you lived through every one of these layers.

E-discovery went from Concordance to Relativity. If you’re old enough to remember Concordance, you remember the experience. It had a GUI, technically. A Windows desktop app with menus, toolbars, and resizable panes. But “graphical” is generous. The interface looked and felt like a database application from the late 1990s, because that’s exactly what it was.

But the search engine was legitimately powerful. Boolean operators, proximity searches, wildcard characters. If you learned the syntax, you could find anything. The problem was that learning the syntax was its own full-time job, and the tool fought you on everything else.

Then Relativity came along. Web-based. Browser-accessible. Designed so a new reviewer could be productive in minutes instead of days. It added analytics, predictive coding, email threading. It scaled to billions of records where Concordance topped out under a million. By the 2022 ABA survey, Relativity held 43% of the market. Concordance had dropped to 12.7%, marketed mainly as a repository for archived matters.

Easier to use. More polished. And also: more locked in. You worked inside Relativity’s workflows, Relativity’s review paradigm, Relativity’s pricing model. Which oh by the way … Relativity is now asking you to host in their cloud. More lock-in.

Document management followed the same arc. Hard copy files gave way to iManage, NetDocuments, FileSite. Physical filing was chaos, but it was your chaos. You could organize it however your brain worked. The digital systems imposed someone else’s logic. Folder structures, metadata schemas, naming conventions, and version controls designed by a product team that had never seen your workflow.

Time entry went from tracking hours in a spreadsheet to systems like Intapp. More structure, better reporting, less flexibility. The tool got smarter. You got more constrained.

Every single one of these transitions followed the same arc. Easier to use. Harder to bend.

I was always the person trying to bend them.

Not because I wanted to break things. Because the tool never quite fit. The workflow it assumed wasn’t my workflow. The report it generated wasn’t the report I needed. The integration it offered wasn’t the integration that would actually save time.

So I’d tinker. I’d find the workaround. I’d build a macro in the spreadsheet that did what the system wouldn’t. I’d string together three tools to cover the gap that the vendor kept promising they’d close in the next release. I’d find the settings menu nobody else opened and make the software do something it technically could do but wasn’t designed to surface.

I know I’m not the only one. Every legal team has this person. The one who builds the intake tracker in Excel because the matter management system’s intake module doesn’t match how work actually comes in. The one who writes the Outlook rule that auto-sorts client emails because the DMS integration is six months behind. The one who finds the back door.

That instinct is what I’m talking about when I talk about builders. Not software developers. Not engineers. People who see a gap between what the tool does and what the work requires, and close it themselves.

But there was always a ceiling.

The ceiling was code.

You could tinker all day. You could push a spreadsheet to its absolute limit with nested formulas and conditional formatting. You could configure a system until you knew the admin panel better than the vendor’s support team. But eventually you’d hit the wall. The thing you needed required actual software development. Custom code. An API integration. A script that automated something the GUI never exposed.

And that’s where most people stopped. Not because they lacked the thinking. Because the gap between “I know exactly what this should do” and “I can make it do that” required a skill set that took years to develop. You needed a developer. Which meant you needed a budget, a project manager, a requirements document, a sprint cycle, and six months of waiting.

Or you submitted a feature request to your vendor and hoped.

Gartner found that 41% of enterprise employees were already building or acquiring technology outside of IT’s visibility. Shadow IT. Not a security failure. A creativity failure. People needed to build, and the tools wouldn’t let them.

That ceiling just collapsed.

Here’s what changed. AI coding agents don’t add another abstraction layer on top of the stack. They give you a path through it.

Tools like Claude Code, Codex, and GitHub Copilot don’t require you to learn Python or JavaScript. They require you to know what you want and to describe it clearly. That’s a different skill. And it’s a skill that lawyers, specifically, are already good at.

Think about what lawyers do every day. Analyze a complex situation. Identify the relevant variables. Articulate a precise outcome. Structure an argument that accounts for edge cases. That’s prompting. That’s system design. That’s exactly what an AI coding agent needs from you.

The numbers are already proving it out. Seventy-five percent of Replit’s users never write code. They describe what they want. A quarter of Y Combinator’s recent startup cohort has codebases that are 95% AI-generated. GitHub Copilot now has 20 million users, and its active users report that it generates 46% of their code. Gartner projects citizen developers will outnumber professional developers 4:1 at large enterprises by the end of this year.

This isn’t about replacing developers. It’s about what happens when the ceiling lifts.

Take something as simple as Google Sheets. You’ve used it. You’ve probably hit its limits. You know there are things you want the spreadsheet to do that formulas can’t handle.

Google Sheets has a built-in tool called Apps Script. It’s JavaScript that lives inside the spreadsheet and works like code. It can send emails, connect to APIs, generate documents, sync across services. Before AI, using it meant learning to program. Now, you describe what you need in plain English, an AI writes the Apps Script, and you paste it in. A capability that was walled off behind code is suddenly yours.

That’s one spreadsheet. Now multiply it across every tool your legal team uses. The contract tracker that should flag renewal dates and notify the business owner. The intake form that should auto-route based on matter type and risk level. The NDA playbook that should update itself when the template changes. The outside counsel report that should pull from three systems and land in someone’s inbox every Monday.

All of those are buildable. Right now. Without a developer. By the person who understands the work best.

The vendors know this is happening.

TechCrunch reported this month that investors have been selling SaaS stocks since late January. They’re calling it the SaaS-pocalypse. The economics of “pay us monthly and wait for the features you need” start breaking down when the end user can just build the feature themselves.

A marketing team at AppDirect built 11 projects without engineering involvement, saving over $120,000 in software costs. The low-code market is projected to reach $44.5 billion by the end of this year.

The abstraction tax. That’s what it was. Every layer that made software easier to use also made it more expensive to escape. For decades, you paid it because you had no alternative.

Now you do.

The instinct was never the problem.

I think about that kid sitting in front of the IBM with the white cursor. No menus. No buttons. No guardrails. Just a blinking line and a castle made of ASCII characters, waiting for you to type what you wanted to do next.

That directness got buried under forty years of abstraction layers. Layers that made technology more accessible, yes. But that also trained an entire generation of professionals to believe they weren’t “technical.” That building things with software was someone else’s job. That the right response to a gap in your workflow was to submit a ticket and wait.

The builder instinct didn’t die. It got pushed underground. Into the macros, the workarounds, the admin panel deep dives, the duct-taped integrations that held your team together while you waited for the vendor to catch up.

AI didn’t give you that instinct. You’ve had it the whole time. It shows up every time you look at a tool and think “this should work differently.” Every time you build a tracker that nobody asked for because the existing system doesn’t do what the work requires.

What changed is the ceiling. You don’t need to become a software developer. You need to understand the architecture of what you’re building well enough to describe it clearly. The same skill that made you dangerous in Concordance’s search syntax. The same skill that made you the person who could actually make the tools work.

From C:\> to a Claude Code prompt. The interface looks different. The instinct is the same.

The question isn’t whether you can build. You’ve been building your whole career.

The question is whether you’ll keep tinkering at the edges, or finally build the thing.

PossibLaw. Substack. Podcast. Tools to become a builder.

We run custom training for legal teams who are done watching from the sidelines. Let’s talk.

The billable hour is a container.

That’s the insight I missed for years, and the one I think most of the profession is still missing. The hour was never the point. It’s the packaging. And the legal industry is arguing about whether to throw out the packaging while ignoring the fact that what goes inside it is about to change completely.

For decades, the billable hour contained one thing: a lawyer’s time. One person, one desk, one task, one increment of effort measured in six-minute blocks.

That container is about to hold something very different. The technology investment. The workflow automation. The work that junior associates used to do. The AI-driven research and drafting that used to take a team a week. The judgment that makes the output trustworthy. The expertise that took 15 years to build. All of it, packed into a single unit of billing that procurement can process, finance can accrue, and the general counsel doesn’t have to fight for internally.

The rate goes up. The hours go down. The total cost stays roughly the same.

This isn’t the final destination. Eventually, the profession will arrive at true outcome-based pricing. But that transition requires infrastructure that doesn’t exist yet: new billing systems, new data standards, new ways for finance teams to accrue and report and allocate. That takes years.

In the meantime, the billable hour is the bridge. And everyone will be fine walking across it, because they know what’s inside: the full capability, not just a person sitting at a desk.

I know this because I tried the alternative. I built the better model. And I watched it break against the exact infrastructure that the billable hour slides through without friction.

The model that should have worked

In Part 1, I told the story of Christensen’s milkshake and the Jobs to Be Done framework: every hiring decision has a functional layer, an emotional layer, and a social layer, and if you only see the functional job, you build the wrong thing.

When I was building Camber Legal, my subscription-based B2B collections litigation company, I wish I’d had that framework. Not because it would have changed the model. But it would have changed how I sold it.

Camber Legal was a hybrid law firm and legal tech offering. We built process automation inside Microsoft Teams to deliver legal services through a monthly subscription. Collections litigation has massive volume but terrible economics on an hourly basis. The amount in dispute often doesn’t justify the legal spend to recover it. We flipped the math: a minimum viable subscription tied to success fees on recoveries, and then it was on us to drive profit by automating everything we could.

Clients saw the value immediately. The work product was strong. We were recovering money that would have otherwise been written off.

And then we’d walk into a meeting with a Fortune 500 legal department, and the conversation would go sideways in the last 15 minutes.

The wall was three walls

The general counsel got it. The lawyers managing the collections portfolio wanted to start yesterday.

And then the deal would stall. Not in one place. In three.

Procurement: “We only do hourly billing. We could look at an alternative fee, but we’d need you to track your time.”

Finance: “How do we accrue this? Our systems need line-item data.”

And the GC’s office would quietly step back. Not because they stopped believing in the value. Because they didn’t want to be the person who forced a non-standard vendor through a process that wasn’t built for it. If something went wrong downstream, a reporting issue, an audit flag, a budget variance, the decision traced back to them.

Every time. Not one gatekeeper. Three. Each with a legitimate reason. None about the quality of the work.

I refused to track time. Any hour we spent documenting our work for someone else’s accounting system was an hour not spent on the actual work or building the technology. That tracking didn’t create value for the client. It created data for a back-office workflow designed to audit hourly invoices.

I thought the problem was cultural. I was wrong. The problem was structural.

Share

Subscribe now

Why the container is hourly-shaped

Enterprise Legal Management platforms were architecturally built to audit hourly invoices. Their core function is validating line-item data: which timekeeper, what rate, which task code, how many six-minute increments. Even a modern platform like Brightflag, which supports fixed-fee submissions as a separate workflow, still processes nearly half of all US-headquartered client invoices as PDFs. The most widely used billing format, LEDES 1998B, has 24 fields almost entirely built around hourly timekeeping. It doesn’t support alternative fee arrangements at all.

But the problem compounds downstream. Finance needs to accrue legal costs monthly. With hourly billing, that’s straightforward: hours times rate. With a flat fee, the “percentage complete” question has no clean answer. How much of a $50,000 subscription has been “earned” by month three? Without hourly data as a proxy, the accrual becomes a guess. Fortune 500 finance departments don’t guess.

Tax teams need granular data too. R&D credits require evidence of time on qualified activities. GAAP rules require certain legal costs to be capitalized, not expensed, and that requires activity-based proof. The CFO’s office doesn’t care whether the billable hour measures legal value. They need data that fits their reporting systems. Those systems speak one language.

And the GC, caught in the middle, does the rational thing: defaults to hourly. Not because it’s the best deal. Because it’s the only model where every system and every stakeholder works without a workaround.

Companies even agree to flat fees and then require law firms to submit shadow invoices showing the hours anyway. If the firm uses technology to finish faster, the shadow bill shows fewer hours, and the client uses that to negotiate a lower fee next time. The firm gets penalized for the efficiency the alternative fee was supposed to reward.

I was selling to the person who valued the outcome while ignoring the people who controlled the process. In a Fortune 500 company, process wins every time.

What goes inside the container now

Jessica Markowitz, President and COO of Paragon Legal Services, got me noodling this idea in a LinkedIn post a few months back. The billable hour rate structure will simply continue to rise. Technology, process automation, the work that junior associates used to do: all of it folded into the hourly rate. The hour becomes a function for evaluating value, not a measure of labor. It works because it’s easier for the law firm and easier for the corporates.

That clicked for me, because I lived the opposite experience. I tried to deliver value outside the container, and the container won.

If I’d priced Camber Legal’s work as a very high hourly rate with a guaranteed estimate of hours, the total cost would have been identical. “This matter will take 10 hours at $5,000 per hour. If we finish in 8, you pay for 8.” Procurement could process it. Finance could accrue it. The GC wouldn’t need to spend political capital getting a non-standard vendor past three teams. Same value. Different container.

Generative AI makes this math real. When I built Camber Legal, it was before the current generation. The compression wasn’t dramatic enough to make a very high rate look reasonable. The work still took meaningful time.

Now? A task that used to take 10 hours at $750 per hour generated a $7,500 bill. AI compresses that to one or two hours. The rate goes to $3,750 or $7,500 per hour. Same total bill. The line item still says “2.0 hours” and every system in the building can process it.

Am Law 25 partners already bill over $2,000-$4,000 per hour. Rates have been climbing 7 to 9 percent annually. AI just makes the compression honest: the rate reflects the capability being delivered per unit of time, not the labor.

Jeff Bleich, Anthropic’s General Counsel, said it plainly at the ABA White Collar Crime Institute: the billable hour has been dying for a long time, and AI will accelerate that death. He’s right about the acceleration. But I think the more interesting development isn’t whether the hour dies. It’s that AI fills the container with something entirely different. Clients aren’t hiring hours. They’re hiring outcomes, trust, insurance. The billable hour is just the container those get delivered in.

Who fills the container

If the value of an hour is about capability delivered, then the lawyer who can architect AI-powered workflows is fundamentally more valuable per unit of time. This is the convergence I wrote about in Part 1: lawyers and software engineers headed toward each other. Not because lawyers need to become programmers. Because the skills that create value in a compressed-time model are systems thinking, workflow design, and building processes that compound.

If an hour now contains 10 hours of compressed capability, the lawyer delivering that hour needs to actually possess the capability. How to design the workflow. How to validate the output. How to build the guardrails. That’s not a prompt engineering skill. That’s a builder skill.

The lawyer who builds commands the premium rate because they earned it. The lawyer still doing the same work at the same speed isn’t compressing value. They’re falling behind on a rate curve that’s moving without them.

The container, redefined

The billable hour won’t die because it doesn’t need to. What’s changing is what goes inside.

Will it be the container forever? No. Eventually ELM systems will process outcome-based fees natively. Data standards will evolve. Finance teams will develop accrual models that don’t need hourly proxies. When that happens, the profession will complete the transition.

But today, the billable hour is the bridge. The rate rises to reflect the actual job being done. Everyone can live with it, because nobody has to blow up their infrastructure to get there.

I learned this the hard way. The lesson wasn’t that alternative fees don’t work. The lesson was that the fastest way to change what gets delivered isn’t to fight the container. It’s to fill it with something better.

That’s the job to be done.

Subscribe now

Leave a comment

The legal professionals who will thrive in the next decade won’t be the ones who know the most. They’ll be the ones who build the best systems.

Not systems as in software. Systems as in: repeatable ways to deliver confidence, speed, and outcomes that clients actually pay for. The professionals who think in workflows instead of tasks. Who design their practices like architects instead of patching problems like on-call fixers.

This isn’t a prediction. It’s already happening. Harvey AI hires “Legal Engineers” with both BigLaw experience and systems design skills. Linklaters built an entire Practice Innovation team. Stanford is running Agentic AI bootcamps for law students. Artificial Lawyer just called “vibe coding lawyers” the dominant conversation at legal tech gatherings.

But why? Why now? Why does the builder’s advantage compound specifically at this moment?

Because AI just exposed a truth the profession has been dancing around for decades: the job clients are hiring lawyers to do has never been the job lawyers think they’re selling.

And if you can’t see the real job, you can’t build the system to deliver it.

There’s a framework for this. It comes from a man who spent 18 hours watching people buy milkshakes.

The milkshake, the commuter, and the job

Clayton Christensen’s team sat in a fast-food restaurant watching milkshake purchases. They’d already tried the obvious approach. Survey customers. Improve the product. Chocolatier. Cheaper. Chunkier. Sales didn’t move.

But the observation changed everything. Half of all milkshakes sold before 8:30 AM. Lone commuters. No kids. Straight to the car.

When asked what “job” they hired the milkshake to do, nobody said dessert. The job was: keep me occupied during a boring 40-minute commute. Something thick enough to last, interesting enough to break the monotony, easy enough to handle with one hand on the wheel.

The milkshake wasn’t competing with other milkshakes. It was competing with bananas, bagels, and silence.

When they redesigned around the actual job, sales went up seven-fold.

This is Christensen’s Jobs to Be Done framework. Customers don’t buy products. They hire them to do a job. And every job has three layers:

The functional job is the task. Draft the contract. Research the precedent. Close the deal.

The emotional job is how the buyer wants to feel. Confident they haven’t missed anything. Protected from exposure. Less anxious at 11pm about what they might have overlooked.

The social job is how they want to be perceived. Competent to their partners. Credible to the board. Defensible in their decisions.

Most legal technology, law firm marketing, and career development focuses on the functional layer. Faster research. Smarter review. More efficient workflows.

But the functional job is almost never the reason someone hires a lawyer, buys a legal tech product, or decides whether to adopt a new tool.

The emotional and social jobs are.

This is why builders win. Because building a system requires understanding the real job. Reacting to tasks only requires understanding the stated one.

Let me show you what this looks like.

Subscribe now

Four people. Four real jobs. Four opportunities to build.

The GC who isn’t buying expertise

New GC. Fortune 500 company. Inherited a panel of twelve outside firms. The CEO wants outside counsel spend cut 15% without increasing risk.

She could negotiate rates. Consolidate the panel. Bring categories of work in-house. The data says 64% of in-house counsel expect to reduce reliance on outside counsel with help from AI.

But here’s what she’s actually navigating at 2 PM on a Wednesday when the head of sales calls about a customer threatening litigation over a failed implementation.

She’s not thinking about rate cards. She’s thinking: who do I call that will pick up immediately, understand the business context without a 45-minute download, and give me a confident recommendation I can relay to the sales VP before his 3 PM meeting?

Speed. Context. Confidence she can hand to a non-lawyer who needs to make a business decision in the next hour. That’s the job.

The firm that wins this work won’t be the one with the lowest blended rate. It’ll be the one that has built enough context about her business that the 2 PM call takes 12 minutes instead of 45. That’s a knowledge architecture problem. It requires compounding relationship context over time through tooling and workflow design, not just good lawyers with good memories.

And she’s navigating a social job she’ll never say out loud. If she consolidates the panel and one of the cut firms was handling a matter that blows up six months later, she owns that outcome. If she keeps the incumbent and it goes sideways, the decision is defensible. This is the “nobody gets fired for hiring IBM” dynamic, and it shapes GC behavior far more than any pricing conversation.

The builder’s advantage for this GC: design an intake and triage system that routes work based on actual complexity, not relationship inertia. Build a knowledge base that captures firm-specific context so the 2 PM call never requires a 45-minute download. Architect the panel around jobs to be done, not practice area labels.

The GC who doesn’t build will keep managing a panel through spreadsheets and instinct, and the CEO’s 15% target will remain a negotiation exercise instead of an operating model.

The legal ops lead who solved the wrong problem

Legal ops. Mid-size legal department. She spent four months evaluating CLM platforms. Business case approved. Vendor selected. Implementation started.

Eight months later, adoption is at 40%. Sales still emails contracts as attachments. Half the legal team routes around the system. Her business case is underwater.

She didn’t fail at technology selection. She failed at job identification.

The CLM vendor said the job was “manage contracts from creation to renewal.” That’s the vendor’s job. It was never the user’s job.

Sales wants to close the deal before quarter-end. Legal wants to approve without being the bottleneck. The CFO wants to know what the company is committed to without asking legal. Three different people with three different jobs. None of them is “adopt a cross-departmental workflow platform.”

Bob Moesta, who co-created JTBD with Christensen, explains why this happens. People switch products when the push of dissatisfaction plus the pull of the new exceeds the anxiety of change plus the habit of the present. CLM carries massive change anxiety: 12-to-18-month implementations, mandatory retraining, systems that collapse with outside parties who won’t adopt your workflow. And the habit of email-plus-Word is so entrenched it might as well be muscle memory. The math never closes, no matter how good the demo was.

The builder’s advantage for legal ops: stop evaluating platforms. Start mapping jobs. Build lightweight, modular systems that serve each stakeholder’s actual job without requiring behavior change that nobody signed up for. An NDA self-service portal for sales. An approval queue for legal. A reporting layer for the CFO. Three small systems that each serve a real job, built incrementally, instead of one monolithic system that serves a vendor’s vision of the job.

Gartner says nearly half of CLM implementations fall short. Christensen estimated 75-85% of new products fail because they miss the real job. Same root cause. The legal ops leaders who succeed won’t be the best tool pickers. They’ll be the best job identifiers.

The associate who isn’t worried about research

9:45 PM. Fourth-year associate. Transaction closing Friday. The partner forwarded diligence documents at 6 PM with a note: “flag anything unusual by morning.”

She’s not worried about whether she can find the issues. She’s been reviewing data rooms since her first year. She’s good at this.

She’s worried about what she might miss.

That’s the emotional job. Not “review these documents.” The job she’s actually doing at 9:45 PM is: build enough confidence that when she sends the memo at 7 AM, she won’t get the call at 10 AM about the change-of-control provision buried in an amendment to Schedule 4.

Now put Harvey or Legora in front of her. The vendor pitch is speed: “Review a data room in hours instead of weeks.” Fine. That’s the functional job.

But that’s not why she’d use it. She’d use it because it gives her a second pass. A safety net. Something to compare her own work against. The real job the tool is hired for: reduce the anxiety that I missed something.

A lawyer who understands this builds differently. She doesn’t just use the AI tool. She designs a validation workflow: her review, the AI’s review, a structured comparison that catches discrepancies. She builds a process she can run on every data room, every time, and hand to a junior associate who can execute it with the same confidence.

That’s the builder’s advantage. She didn’t just get faster. She designed a system that produces verifiable, repeatable assurance. The next deal, and the one after that, and the one after that, all benefit from the architecture she built tonight.

The associate who doesn’t build? She’ll use the tool ad hoc, feel a little less anxious, and start from scratch on the next deal.

The solo practitioner who isn’t practicing law

Solo. Family law. She does good work. The problem is she only gets to do it 55% of the time.

The rest is intake calls, calendar management, billing, follow-ups, client communications, and bookkeeping. Clio’s data shows the average lawyer bills 2.9 hours in an 8-hour day. She’s losing over $100,000 a year in time that never reaches a client.

When she looks at AI tools, the vendor pitch is “draft documents faster.” But drafting isn’t her problem. She drafts fine. Her problem is she can’t get to the drafting because everything else eats her day first.

Her real job to be done for technology: help me run a business when all I was trained for is practicing law.

The builder’s advantage here is the most tangible of all. She doesn’t need to become a software engineer. She needs to look at her practice as a system with inputs, processes, and outputs instead of a collection of individual matters. Where are the bottlenecks? What repeats? What can she automate not by buying a single tool but by designing a workflow?

A lawyer who builds an intake automation that connects to scheduling, routes to a document assembly pipeline, and triggers a client communication sequence has done something more powerful than adopting any single product. She’s built an operating model. She’ll recover those lost hours not by working faster, but by designing her way out of work that never required a licensed attorney in the first place.

The solo who doesn’t build will keep losing half her day to admin and wonder why revenue stays flat while she works harder.

The pattern underneath

Every one of these people faces the same gap.

The associate isn’t hiring AI for speed. She’s hiring it for confidence. The GC isn’t hiring outside counsel for expertise. She’s hiring them for context and career protection. The legal ops lead isn’t hiring a CLM for contract management. She’s hiring it to reduce friction for people who don’t care about contract management. The solo isn’t hiring technology for drafting. She’s hiring it to recover the half of her day that admin stole.

In every case, the real job is emotional or social, wrapped inside a functional request. And in every case, the person who wins is the one who identifies the real job and builds a system to serve it.

This is why the builder’s advantage isn’t just a career differentiator anymore. It’s becoming the dividing line.

The legal profession is converging with software thinking. Not because lawyers need to write code, though that’s increasingly useful. Because the skills that create value in a world where AI handles the functional layer are the same skills engineers have been developing for years: systems thinking, workflow design, architecture that compounds, processes that scale.

The lawyer who can identify the real job, design a system to deliver it, and build the workflow that produces repeatable outcomes isn’t just more efficient. They’re playing a different game. They’re not fixing today’s problem. They’re building tomorrow’s operating model.

Moesta said it plainly: “Adding more features is not better because it causes additional anxiety.” In a profession organized around risk aversion, more features means more anxiety, more switching costs, more reasons to stay with email and Word. Builders cut through that by designing around the real job. Fewer moving parts. Less behavior change required. Higher confidence delivered.

The firms, legal departments, and solo practices that internalize Jobs to Be Done will make different technology decisions, different hiring decisions, and different career bets. They’ll stop asking “what does this tool do?” and start asking “what job is this person actually trying to accomplish, and does this tool serve that job or add anxiety to it?”

That one question is worth more than every feature comparison matrix ever built.

In Part 2, we’ll take this framework and apply it to the economics: what happens to the billable hour when the job gets done in one-tenth the time, and why the answer isn’t only flat fees. It’s an ever escalating hourly rate that neatly fits into current procurement team systems and should make managing partners very interested.

One move: pick one task you did this week. Don’t describe the task. Describe how you wanted to feel when it was done. That feeling is the real job. Now ask whether your current tools and workflows serve that job, or just the task.

Subscribe now

Share PossibLaw

A fellow legal innovator, made a smart point recently: most lawyers will use AI the way most people use grocery stores. Why forage for your own food when someone’s already done the work?

I get the instinct. But I think the analogy lands in the wrong place. So I’m going to replace it with a different food analogy and stretch it until it snaps.

Here’s what I actually think is happening:

The frontier models (Claude, GPT, Gemini) are the grocery store. Raw ingredients. Available to anyone. Remarkably good ingredients, honestly. Better every month.

The legal tech vendors selling you prepackaged AI tools? Those are restaurants. Solid restaurants, some of them. But you sit down, you eat what’s on the menu, and you go home. You didn’t cook anything. You don’t know how. And if the restaurant closes, raises prices, or decides salmon is off the menu this quarter, you’re stuck.

Now here’s where I really commit to this bit.

Humanity did not stop cooking at home when restaurants got good.

The opposite happened. Food blogs became the single most lucrative blog niche. YouTube cooking channels became the platform’s 4th largest content category. Farmers markets grew five-fold. During COVID, yeast purchases spiked 647% in a single week and flour couldn’t stay on shelves. People didn’t just keep cooking. They went deeper: fermentation, sourdough, charcuterie, fresh pasta.

And the restaurant industry also grew to $1.5 trillion.

It was never a zero-sum game. Better restaurants inspired better home cooks. Better home cooks became more adventurous restaurant customers. The whole ecosystem expanded.

So that same cooking flywheel is spinning up in law right now. For one simple reason.

Building things rewires your brain

This is the part that matters most, and the part most people skip past.

People don’t cook at home only to save money. They do it because it changes how they relate to their life.

Researchers mapped cooking behavior onto a well-being framework and found that making your own food activates all five dimensions of human flourishing: positive emotion, engagement (genuine flow states), relationships, meaning, and accomplishment. Cooking interventions consistently increase confidence and improve general and mental health measures. UC Berkeley’s Greater Good Science Center put it plainly: cooking is an act of empowerment because it provides control, nurtures confidence, and builds autonomy.

They also documented something called the “I made it myself” effect. People consistently rate self-prepared meals higher than objectively similar meals made by others. Not because the food is better. Because they built it.

That same rewiring is what happens when a lawyer stops buying prepackaged tools and starts building their own. And I don’t mean “doing it manually.” I mean cooking.

Here’s what usually happens:

It’s 9:43 p.m. One screen still on.

Partner wants a risk memo in the morning. Client changed one clause. Again.

You open the vendor tool. It has a workflow for “standard risk memo.” You paste the clause, click generate, and get something... fine. Not your fine. Generic fine. You start patching it, sentence by sentence. You can’t change the structure without breaking the tool’s logic. You can’t swap in your client’s definitions cleanly. You can’t reuse the fix next time without doing this dance again.

You ship it anyway, tired and slightly annoyed.

Same night, different move. You open the frontier model with your own small set of saved building blocks. Your clause library is already tagged. Your playbook is already outlined. Your prompt pulls the right definitions, compares to your fallback positions, drafts the memo in your voice. You change one instruction, rerun the same recipe, and the whole memo updates consistently. You ship it, then you keep the recipe. Next time is cheaper.

The second lawyer didn’t just get a better memo. They learned something. They saw how the model reasons about risk clauses. They understood what prompts surface which edge cases. They iterated until the recipe matched the exact way their practice thinks about liability. Every rep compounded their understanding.

The tool got better because the lawyer got better. The lawyer got better because the tool revealed new patterns.

That’s the difference between a home chef and a restaurant customer. The home chef has skills that transfer, compound, and adapt. The restaurant customer has a reservation.

Share

When you only eat vendor outputs, you inherit their defaults

Think about what you’re actually accepting when you click “generate” inside a prepackaged tool:

• Their definition of what “good drafting” means

• Their opinion on what sources count

• Their preferred structure

• Their blind spots on edge cases

• And oh by the way, you are teaching them a better recipe.

When you cook, you can be opinionated. You can adapt. You can make exactly what the matter needs, even when the matter is weird. Especially when the matter is weird.

This isn’t theoretical. It’s already happening.

On February 3, 2026, Anthropic launched a legal plugin for Claude. Within six trading days, $830 billion in market value evaporated from software and services stocks. Thomson Reuters fell 16%. RELX dropped 15%. Wolters Kluwer fell 13%.

The market read this as a threat to legal tech vendors. That framing is mostly wrong, and it misses the real story.

The real story is what lawyers are doing with the raw ingredients.

Jamie Tso, a senior associate at Clifford Chance in Hong Kong, vibe-coded a range of legal AI tools that replicate capabilities offered by major legal tech companies. His LinkedIn post sharing the work sparked what Artificial Lawyer called “a movement.” His GitHub repos have been forked over 100 times. He started a group chat of lawyers who call themselves “legal quants.”

Tso’s trajectory is the home chef trajectory. He started experimenting with no-code tools his firm made available. Hit the limits. Taught himself to code on weekends. Now he’s exploring concepts like contract simulation, spawning AI personas to simulate clause disputes before signing. His vision: just-in-time, disposable software built to solve a specific pain point, then replaced when the workflow changes.

He’s not the only one. The National Law Review ran “Why Smart Lawyers Are Building AI Tools Instead of Buying Them,” noting that vibe-coded tools encode lawyer judgment directly rather than imposing predefined structures. Linklaters identified 400+ potential AI use cases through internal innovation groups. Jordan Bryan’s newsletter “The Redline” published “The Future of Legal Tech Will Be Built by Lawyers.”

Duquesne’s Kline School of Law captured the identity shift best: when law students use pre-existing legal tech, they are consumers of a finished product. When they learn to build, they transition from consumers to creators. They become the architect of the system.

The new kitchen

The grocery store now comes with appliances.

MCP (Model Context Protocol) is the farmers market: high-quality raw materials, universally accessible, with thousands of community-built connectors to the tools lawyers already use. Claude Code is the well-equipped kitchen. Plugins are the specialty tools: the stand mixer, the pasta roller, the fermentation crock.

And the restaurants aren’t going anywhere. Harvey AI raised at an $8 billion valuation. CoCounsel just crossed one million users. Complex, mission-critical legal work will continue to need industrial-grade platforms, just like complex meals still send people to great restaurants.

But the ecosystem is expanding. The lawyers who learn to shop at the grocery store, who understand what ingredients exist, how to combine them, how to iterate on their own recipes, those lawyers will have something no prepackaged tool gives them: control over what they’re making. And that control compounds.

There’s a reason people kept baking sourdough after lockdown ended. It wasn’t about the bread. It was about what making the bread did to them. It rewired how they thought about food, ingredients, process, craft.

Building your own legal tools does the same thing to how you think about law.

I warned you about the analogy. You stayed anyway. That means you’re probably one of them.

One move: write one “house recipe” for a recurring work product this week. A risk memo template, a clause fallback workflow, a diligence summary prompt. Save it. Reuse it twice before you let yourself touch a vendor template. See what you learn about how the work actually works.

Subscribe to PossibLaw. Substack. Podcast. Tools to become a builder.

They also dive into what’s changing inside the legal industry right now: sharper risk assessment, better business decisions, and how technology, automation, and legal tech are reshaping how firms operate. Travis breaks down what responsible experimentation with artificial intelligence and deep learning looks like in a real firm—how to evaluate vendors, avoid hype, and build a culture of curiosity and adaptability (without sticking your head in the sand).

Along the way, they touch on parenting, relationships, and the success habits that compound over time—especially for lawyers and legal professionals who want self development, self help, and self improvement that actually works.

Listen to the entire podcast and learn even more!

Takeaways

• Success is usually non-linear—your journey matters as much as your destination.

• Community is built through shared challenge, not transactional networking.

• Relationship-building beats “used car salesman” energy every time.

• Being an entrepreneur is a mindset, not just starting a startup.

• Build your career with intention: work backward from where you want to land.

• Firms are businesses—understand overhead, margins, and what “success” means.

• Tech adoption requires curiosity + governance (especially with confidential data).

• Legal AI is powerful, but data sources + nuance still matter more than hype.

• Practice areas with repetition will see faster automation and consolidation.

• Domain expertise + creativity remain differentiators in complex legal work.

👤 Guest Bio

Travis West is a veteran, attorney, and entrepreneur focused on service-driven work, building community, and helping teams adapt to change. His career blends law, leadership, and technology-minded thinking—grounded in real-world life lessons and a commitment to doing hard things.

🔗 Connect With Travis

• LinkedIn: https://www.linkedin.com/in/travisjameswest/

• West & Dunn: www.westdunn.com

🔗 More From Salvador Carranza

• PossibLaw: www.possiblaw.com

• LinkedIn: https://www.linkedin.com/in/salvadorcarranza/

👉 Subscribe to PossibLaw. We’re ReCoding the Vibe in the legal industry by empowering creativity. Our mission is to be your guide to the future of legal by identifying and analyzing Builders—individuals who don’t merely inhabit an industry, but actively construct new systems, workflows, and paradigms within it. We aim to prove that anything is possible. Subscribe, pull up a chair, and let’s invent what’s next, together.

⏱️ Chapters

00:00 – Welcome to PossibLaw (possiblaw) + why success is non-linear

01:00 – Travel, family, parenting, and perspective

06:15 – Why Travis chose military service (before 9/11)

10:00 – The Ranger path: challenge, identity, and purpose

22:00 – Community, camaraderie, and what “earned your seat” means

33:00 – Networking that isn’t transactional: how relationships actually work

42:00 – Starting a firm: the founder journey, risk, and real-world lessons

58:00 – Tech stack choices, remote work, and experimenting with AI tools

01:13:00 – Where law is going: ownership rules, consolidation, and innovation

01:21:45 – Actionable advice: curiosity + entrepreneurial mindset

01:26:00 – Closing thoughts

Share

The Front Door Is Moving

For over a century, the front door to legal services was a conversation with a human attorney. A handshake. A retainer. A relationship.

That front door is now a prompt.

Google’s AI Overviews answer “Do I need a lawyer for a first DUI in Texas?” before the user ever sees a law firm’s website. ChatGPT drafts NDAs. Harvey redlines merger agreements. Ironclad measures success by contracts that close without legal review.

The invisible constraint people always forgot? Lawyers were never selling expertise. They were selling access. Access to knowledge locked behind bar exams, Latin phrases, and $1,500-per-hour gatekeeping.

AI didn’t kick down the front door. It built a new one.

And if you think this is hypothetical: that AI is hype, that it won’t affect your practice, that the legal profession is somehow immune, let me show you what happened to an industry that thought the same thing.

The Travel Industry Wrote Your Future: A Case Study

is a cloud software analyst at Altimeter Capital. He doesn’t follow the legal industry. He follows what happens when software reshapes how customers access services. And he identified a pattern that should terrify every lawyer who thinks AI is “just hype.”

Ball distinguishes between two types of software in any industry:

• System of Record (SoR): The database where truth is stored

• Front Door: The interface where work is initiated

For decades, the travel industry’s System of Record was the Global Distribution System—the database connecting airlines, hotels, and rental cars. Companies like Sabre and Amadeus built this infrastructure.

But the front door? That was the travel agent.

Travel agents were the human interface. They knew how to navigate the GDS systems. They understood fare classes, routing rules, and booking codes that were impenetrable to ordinary consumers. They translated complexity into action. You told them where you wanted to go; they made it happen.

Sound familiar?

Then Expedia and Booking.com arrived.

These online travel agencies didn’t build better databases. They didn’t own hotels or fly planes. They did one thing: they replaced the human interface with a software interface. They became the place where customers started their journey—and they cut the travel agent out entirely.

The results?

Booking Holdings, New Front Door: Market Cap: $164 Billion

Sabre, System of Record: $477 Million

Read that again. The company that owns the interface is worth 344x more than the company that owns the system of record.

Sabre still processes reservations. Amadeus still runs the backend. But they’ve been reduced to utilities—commoditized pipes that the front door companies pay pennies to access.

The travel agents disappeared.

Remember travel agents? They were the human gatekeepers—the licensed professionals who knew the systems, understood the options, and guided you through complexity. For decades, you couldn’t book a flight or hotel without going through them.

Expedia didn’t just digitize what travel agents did. It replaced them entirely. The number of travel agents in the U.S. dropped from 124,000 in 2000 to around 60,000 today—and those who remain serve narrow niches that software can’t easily replicate.

Want a concrete example? In 1994, Carlson Wagonlit Travel became the largest travel agency in the world with approximately $9 billion in revenue. They were the Kirkland & Ellis of travel—the dominant player, the gold standard. In 2025, they were sold to Amex Travel for $570 million. That’s a 94% collapse in value over three decades.

The travel agents were the lawyers of the travel industry. They were the front door. And when software built a better door, even the biggest players got locked out.

This is what Ball calls “value inversion.” When software captures the interface, the interface captures the economics—and the human gatekeepers become optional.

Now Apply This to Law

The legal industry is a $1 trillion global market. In the U.S. alone, law firms generate over $350 billion annually.

For over a century, the “front door” to this market was a conversation with a licensed attorney. Lawyers were the interface. The System of Record—case law, statutes, regulations—sat behind them, accessible primarily through expensive databases like Westlaw and LexisNexis.

The structure looked like this:

Client → Lawyer (Front Door) → Legal Research (System of Record) → Legal Work Product

Lawyers controlled the interface. They decided what questions to research, what precedents mattered, what arguments to make. The System of Record was powerful, but it required a lawyer to access and interpret it.

AI inverts this structure.

Client → AI Interface (New Front Door) → Lawyer (Backend Resource) → Legal Work Product

When a client asks Harvey to “review this merger agreement and flag the five biggest risks,” Harvey doesn’t call a lawyer. It accesses the legal knowledge base, applies reasoning, and delivers output. A lawyer might review that output—but the lawyer is now downstream of the interface, not upstream.

This is the travel industry pattern repeating. Harvey et al becomes Booking.com. The law firms become Carlson Wagonlit. The lawyers become the niche travel agents.

The Numbers That Should Wake You Up

Kirkland & Ellis—the most profitable law firm on the planet—generated $8+ billion in revenue in 2024.

A legal AI startup with a fraction of Kirkland’s revenue commands a valuation equal to the firm’s entire annual output.

Investors aren’t stupid. They see the travel industry playbook. They’re betting these companies become the Booking.com of legal—capturing the interface, reducing law firms to backend fulfillment.

The math is brutal. Law firms scale like restaurants. Legal AI scales like Netflix.

The $1 Trillion Question

The global legal market is worth $1 trillion. But here’s the number hiding inside that figure:

85% of Americans with civil legal needs can’t afford a lawyer.

That’s not a gap in the market. That’s the majority of the market—structurally locked out by a business model that requires $300-$2000+/hour humans for every interaction.

The $1 trillion we measure today represents only the people and businesses who can pay current prices. The actual demand—the people who need wills, tenant disputes resolved, small business contracts reviewed, employment issues addressed—is multiples larger.

AI doesn’t just threaten the existing $1 trillion. It unlocks the market that was never accessible.

This is why LegalZoom has an Arizona ABS license and a partnership with Perplexity that moves the legal front door to the search bar. This is why Rocket Lawyer built “Rocket Copilot” with seamless human handoff. They’re not competing for the $1 trillion. They’re competing for the $3-4 trillion that could exist if the unit economics worked.

DoNotPay is the cautionary tale—the FTC forced a $193K settlement for unsubstantiated “Robot Lawyer” claims. Pure AI without human guardrails faces regulatory risk. But the winning model isn’t AI or lawyers. It’s AI with lawyers in a fundamentally different role.

Three Layers of Displacement

The front door isn’t moving in one direction. It’s fragmenting across three distinct layers—and each requires a different response.

Layer 1: BigLaw — The Associate Is Already Gone

At elite firms, Harvey et al are doing what first-year associates used to do: document review, initial research, redlining. Thomson Reuters’ “Deep Research” agent doesn’t just search—it plans research paths, executes them, and verifies its own citations.

The firms positioning this as “augmentation” are telling a half-truth. Yes, the associate still reviews the output. But the associate used to generate the output. That’s not augmentation. That’s substitution with a human checkpoint.

The honest question: How many associates does a team need when the AI handles 80% of the volume?

Layer 2: In-House — The General Counsel Faces a Two-Front War

Front one: Platforms like GC AI and Eudia promise that one general counsel can do the work of three. Eudia went further—they became a regulated law firm under Arizona’s ABS rules. They don’t sell hours. They sell outcomes. Their “Company Brain” captures institutional knowledge so it never walks out the door.

Front two: Business units are building their own doors. Ironclad’s “No-Touch Rate” celebrates contracts that close without legal involvement. LinkSquares lets sales managers type “Make this indemnification mutual” and the AI executes. Streamline AI triages 60-70% of intake requests before a human lawyer ever sees them.

The general counsel’s job used to be controlling legal risk. Increasingly, it’s controlling access to legal resources. And the business is building bypass routes.

Layer 3: Consumer — The Door Is Wide Open

Remember that 85% who can’t afford lawyers? They’re not waiting for the bar association to solve access to justice. They’re using ChatGPT. They’re using Google’s AI Overviews. They’re getting answers—imperfect answers, sometimes dangerous answers—because imperfect answers beat no answers.

The platforms that figure out how to serve this market with AI plus appropriate human oversight won’t just capture market share. They’ll create a market that never existed.

Subscribe now

The Architect Lawyer Emerges

So what’s the role that survives—and thrives—when the front door moves?

It’s not the lawyer who knows the most case law. AI has that covered.

It’s not the lawyer who drafts the fastest. AI drafts faster.

It’s not even the lawyer with the best client relationships—because the client relationship is migrating to whoever owns the interface.

The role that survives is the Architect Lawyer.

The Architect Lawyer is software literate—and that literacy pays dividends in two phases.

Phase 1: Today — Buy and Use Technology More Effectively

Right now, software literacy means understanding how technology works well enough to:

• Buy smarter: Evaluate which platforms actually deliver vs. which are vaporware. Know the right questions to ask vendors. Understand what’s technically possible vs. what’s marketing.

• Use dynamically: Go beyond the default settings. Design prompts that get reliable outputs. Chain tools together for complex workflows. Customize platforms to your practice.

• Guide strategy: Understand where technology is heading so you can position your firm, your team, or your career accordingly.

This is table stakes. The lawyers who can’t do this will overpay for tools they underuse, while competitors extract 10x the value from the same technology.

But here’s where it gets interesting.

Phase 2: Tomorrow — Design Solutions That AI Fabricates

Consider how the semiconductor industry works.

Nvidia doesn’t manufacture chips. They design them. So do huge teams at Apple with their M class chips, and thousands more in companies of all sizes. Where does the fabrication plant sit? Well the one that can do the most advanced work, TSMC, is just fine. The one’s that have become commodity driven, Intel et al, falling behind.

The designers capture a significant portion of the value chain.

AI models are becoming the “fabs” of the software world. Today, if you want a custom legal intake system, you hire developers, wait months, and pay six figures. Tomorrow—and “tomorrow” is closer than you think—you’ll describe what you need, and AI will fabricate a working application.

Not a prototype. Not a mockup. A working app.

This is already happening in primitive form. AI can generate functional code from natural language descriptions. The interfaces are clunky, the outputs require refinement, but the trajectory is clear: the bottleneck is shifting from “can you build it?” to “can you design it?”

The Architect Lawyer who understands software frameworks—who can describe a legal workflow precisely, who knows what’s technically feasible, who can validate whether the output actually works—becomes the designer. The AI becomes the fab.

And the designer owns the front door.

What This Means Practically

Think of it this way: You don’t need to be a carpenter to design a house. But you need to understand what wood can do, how load-bearing walls work, and what’s possible within the constraints of materials and physics.

The Architect Lawyer understands what AI can do, how data flows through systems, and what’s possible within the constraints of technology and regulation. They don’t write code—they write specifications that AI turns into code.

Here’s the distinction:

The Architect Lawyer thinks in systems, not tasks. They ask: “How do I solve this problem once, in a way that works for every future instance?” instead of “How do I solve this problem for this client, this time?”

This requires a new kind of literacy:

• Technology evaluation: Distinguishing real capability from vendor hype

• Workflow design: Understanding how to chain tools and processes for complex outcomes

• Specification writing: Describing solutions precisely enough that AI can build them

• Output validation: Recognizing when AI gets it right and when it hallucinates

• Systems thinking: Seeing legal work as repeatable processes, not one-off engagements

This isn’t about becoming a technologist. It’s about becoming fluent enough in technology to direct it—today as a sophisticated buyer and user, tomorrow as a designer whose specifications AI fabricates into working solutions.

The partners at elite firms who command $2,000+ per hour aren’t doing document review. They’re architecting deals—structuring transactions, designing governance frameworks, engineering outcomes. They’ve always been architects. The difference now is that the output of architecture is changing. It used to be documents and advice. Increasingly, it’s systems and software.

The lawyers who develop this literacy won’t just survive the front door migration. They’ll own the next front door—not by guarding it, but by designing it.

The Choice in Front of You

The travel industry didn’t disappear when Expedia captured the front door. Hotels still exist. Airlines still fly. But the travel agents—the human gatekeepers who used to be the mandatory interface—largely vanished. The ones who survived found narrow niches: complex itineraries, luxury travel, corporate accounts. The routine bookings? Gone to software.

The legal industry won’t disappear either. Complex litigation will still need trial lawyers. Bet-the-company M&A will still need dealmakers. Novel regulatory questions will still need experts.

But the routine work—the work that makes up the majority of legal revenue—is moving to whoever controls the interface. And the lawyers who don’t understand this will find themselves in the same position as travel agents in 2005: confident in their expertise, dismissive of the threat, and blindsided when the volume evaporates.

Here’s the difference between lawyers and travel agents: lawyers can design the next front door.

Travel agents couldn’t build Expedia. They lacked the technical literacy, the software frameworks, the ability to even conceive of what was possible. By the time they understood the threat, Booking.com had already captured the interface.

Lawyers have a window. The AI models that will fabricate tomorrow’s legal applications are just emerging. The lawyers who develop software literacy now—who learn to evaluate technology, design workflows, and eventually specify solutions that AI builds—can own the next front door instead of renting access to it.

But that window won’t stay open forever.

What’s your next move? Are you developing the literacy to design the next front door—or waiting until someone else builds it for you?

Subscribe now

Legal is heading toward an uncomfortable truth: the people who shape what’s next won’t just “know the law.” They’ll design the systems that deliver it.

Not because everyone needs to become a developer. But because agency is moving down-stack. From committees to individuals. From vendors to builders. From “gatekeepers” to “architects of defensibility.”

And legal has a problem: it has trained generations of professionals to be brilliant inside a bundle that is breaking.

A year ago, “vibe lawyering” hit a nerve. The point wasn’t the punchline.

A year ago I said “vibe lawyering” out loud: the idea that non-lawyers already do a lot of legal work, and it’s more prevalent than the profession likes to admit.

It got eyeballs because it hit a nerve. Not because it was novel.

The uncomfortable part wasn’t “clients are doing legal work.” They always have. The uncomfortable part was agency: people shipping outcomes without waiting for the legal priesthood to bless every step.

That trend didn’t reverse. It got infrastructure.

The bundle is breaking, and it’s not “innovation”

For decades, the legal services bundle held because producing answers was expensive and verifying them was even harder. The firm sold analysis + legitimacy together.

You didn’t buy a memo. You bought the right to rely on it.

Now we’re crossing a threshold where analysis is getting cheaper faster than verification at scale. That changes the shape of the market.

• Clients internalize production (drafting, issue-spotting, first-pass research).

• They buy legitimacy only when stakes demand it (bet-the-company, novel risk, regulatory edge cases).

• The market doesn’t transfer cleanly to new providers. It shrinks.

This is why so much “innovation” in big law feels like efficiency theater: more cash management, more utilization games, more margin defense. That’s not growth. That’s a business model trying to stay vertical while the value is going horizontal.

Incentives drive the world, and legal’s incentives hate agency

Charlie Munger’s entire point was simple: show me the incentives and I’ll show you the outcome.

Legal’s current incentives produce low agency by design:

• Investment is tied to committees.

• Workflow changes require permission.

• Tooling decisions are centralized.

• The person closest to the friction can’t fix it.

• Inefficiency increases billable hours and the bottom line.

So you get the classic partner experience: “I can change the argument. I cannot, or often, will not, change the process.” The system rewards excellent work inside the box, then acts shocked when no one rebuilds the box.

Also, don’t forget, lawyers have been a cornered resource. A regulated monopoly. Gatekeepers. The high priests. They don’t love intrusion from the peasants.

But monopolies have a tell: they confuse control with value. And when the underlying economics shift, control becomes a cost center.

Share

“Best model” in legal is intelligence × defensibility × control

In most industries, the “best model” is raw capability. In legal, capability alone is not the product. Legal’s product is: intelligence × defensibility × control.

That’s why the market is bifurcating:

• Low end: “probably right” tools, cheap, disposable, fast.

• High end: “provably right” workflows, audited, governed, institutionally owned.

The middle gets crushed.

But here’s the tweak I’d make to the vibe debate:

I don’t buy that vibed software is inherently unverifiable. Assume models can build secure, enterprise-ready apps. Assume the plumbing gets real. Then it’s not only “middle squeezed.” The real fight becomes: who owns the designs.

Do you want to be intel? Or Nvidia?

Because when you can generate software, execution gets cheaper than architecture. The value migrates to:

• the workflow spec,

• the policy and controls,

• the data boundaries,

• the audit trail,

• the institutional “right to rely.”

In other words: the blueprint, not the code.

This is the real strategic question for firms and departments:
Are you building for “probably right,” or are you building for “provably right?”

If you can’t answer that, you are not doing strategy.

Fabless legal tech: the future is custom, not packaged

Here’s the analogy I keep coming back to: Nike is fabless. Semiconductor giants are fabless. They don’t own the factory. They own the design, the supply chain, the standards, and the differentiation.

Legal tech is going the same direction.

Foundation models commoditize general intelligence. What differentiates is domain architecture:

• What you integrate with

• What you log

• What you restrict

• What you can prove

• What you control end-to-end

If models can ship enterprise-grade apps, fabless becomes even more true. The “factory” becomes abundant. Design becomes scarce.

piece on “vibe-coding lawyers” is basically a blueprint for where this goes: lawyers building workflow-specific tools, but inside secure infrastructure with approvals, sandboxing, tests, and governance. That is not “apps.” That is an operating model.

And it points to the real shift: software development becomes a literacy, and legal professionals become the people who specify, validate, and govern systems.

Which brings us back to agency.

Subscribe now

Agency, stacked: firm → department → professional → system

Let’s talk about agency the way it actually shows up.

1) Agency of the firm

Most firms are optimized for defensibility and cash flow. Not iteration.

Big committees. Slow procurement. Change requires political capital. The front door is guarded.

So when AI shows up, the default move is: buy a platform, run a pilot, announce a “transformation initiative,” and call it a day.

Meanwhile, the real leverage is slipping out the side door: the people closest to the work quietly building their own shortcuts.

2) Agency of the legal department

Legal departments are under pressure to ship faster with less. They cannot afford artisanal lawyering for everything.

So they will:

• internalize commodity work,

• automate first passes,

• reserve outside counsel for edge cases and courtroom persuasion.

That is the shrink.

3) Agency of the legal professional

This is the most important layer because it is the layer with the most upside.

The lawyer who can say:

• “Here’s the workflow.”

• “Here are the failure modes.”

• “Here are the controls.”

• “Here’s what we can ship this week.”
  …is going to run laps around the lawyer waiting for the committee.

Den Delimarsky describes this as becoming a “full stack person”: someone who can think across constraints, integration points, trade-offs, and execution speed. He even lists the exact questions architects ask: where friction happens, what paints you into a corner, how you validate output.

That is legal’s new core skillset. Not coding. Architecture.

And it’s the cleanest path to personal agency: if you can design the system, you don’t need permission to be useful.

4) Agency of the system

The legal system itself still has in-person moats:

• courts,

• persuasion,

• human judgment under uncertainty,

• legitimacy rituals.

But everything adjacent gets rebuilt: intake, triage, drafting, negotiation playbooks, compliance monitoring.

And here’s the punchline: the profession won’t be displaced only by “AI.” It’ll be displaced by clients and operators who can design and run legal systems without waiting for lawyers to show up.

The lawyers “out of the loop” become reviewers of machines, not designers of outcomes.

That is a downgrade in power.

So what does the “architect lawyer” actually do?

Not write Python all day.

They do what architects do:

• Define requirements: what “good” means, by role and risk

• Design controls: logging, audit, permissions, data boundaries

• Specify defensibility: what must be provable, to whom, and when

• Build verification loops: tests, checklists, human-in-the-loop gates

• Own integration: documents, matter systems, email, billing, knowledge

• Ship iteratively: small releases, fast learning, real adoption

They also understand the economics: interesting work still needs a payer. If nobody funds strategic work, money moves elsewhere. That is not a moral failing. It’s just gravity.

The Close: Stop tweaking. Start transforming.

Munger warned that old ideas crowd out new ones. People can’t accept the new because they are wedded to the old. Legal has a lot of old ideas. Many of them are billable.

So here’s the practical move if you want agency:

Pick one workflow you touch weekly. Then work backward from the end state:

• Map the steps (including handoffs).

• Name the invisible constraints (approvals, risk gates, missing data).

• Decide the target: “probably right” or “provably right.”

• Design the minimum viable system with controls.

• Ship a prototype inside guardrails, then iterate.

If you can do that, you are no longer just practicing law.
You are building the system that practices it.

And that’s where legal is going, whether the committee approves it or not.

Appendix:

Credit to a long list of insightful thinkers and builders in the AI and Legal space. Check them out, they are brilliant.

Horace Wu

Dom Conte

Den Delimarsky

Usman Sheikh

The Redline by Version Story

The future of Legal Tech will be built by lawyers

One month ago, an associate at Clifford Chance turned the legal-tech world upside down when he shared that he vibe-coded a popular legal AI workflow in a matter of hours. Jamie Tso’s post sparked a movement. Suddenly, lawyers building their own tools with AI is all anyone can talk about…

Read more

4 months ago · 6 likes · 1 comment · Jordan Bryan

Quentin Solt

Has Legora’s CEO let the cat out of the bag?

When legal tech evangelists accidentally reveal the endgame…

Read more

6 months ago · 5 likes · 1 comment · Quentin Solt

The GC paused, looked at the vendor’s glossy slide, and said the quiet part out loud. “So you’re telling my lawyers not to learn this because your model will think for them.” The room nodded. Cheaper. Faster. No homework.
That is the seduction. It is also the trap.

In law, the model is not the point. Judgment is.

The real black box is not the model. It is our training gap.

We talk about AI like it is a mysterious vault. Parameter counts. Hidden layers. Hallucinations. Fine. But there is a second black box hiding in plain sight. It is the human one. We have not trained lawyers to prompt with precision, to interrogate outputs, or to design workflows that make the right use of a probabilistic system. So we blame the model when the process was never taught.

Vendors encourage it. “We abstract away the complexity.” Translation: please do not ask how this works, and please do not measure it against how you think. Partners reinforce it. “Bill your hours, the tools will catch up.” Translation: your value is time spent, not decisions made. Associates internalize it. “If the model is a threat, I should avoid it.” Translation: if I do not look, it cannot replace me.

The friction is structural. Law rewards risk transfer and precedent. AI demands experimentation and feedback. Those incentives collide, and the easiest path is to wait.

What actually matters in legal work

• Framing the question. Most legal errors start here. AI cannot rescue a bad question.

• Decomposing the task. Research, synthesis, options, implications, then drafting. Tools are sharp at some steps, blunt at others.

• Adversarial review. You must try to break your own work. The model will not tell you where it is weak unless you ask in the right way.

• Decision under uncertainty. Clients pay for conclusions with risk ranges, not endless memos.

Training targets these muscles. The model amplifies what exists.

If we train nothing, it amplifies nothing.

Share

Two quick scenes

1) The in-house team and the “magical” brief builder
A Fortune 500 law department licensed an AI drafting tool. Adoption flatlined. Lawyers pasted prompts into a single box, accepted the first output, then quit when it sounded generic. The issue was not the model. The issue was no one taught a 10-minute workflow: outline first, then targeted prompts for sections, then source-anchored quotes, then a contradiction pass. Once trained, average drafting time dropped 35 percent. Quality improved because the humans learned to drive.

2) The litigation associate and the cite check
An associate used AI to speed a cite check. It hallucinated two cases. She caught both because her checklist forced a “verify in database, not in the model” step. Partners now think she is a wizard. She is not. She is trained. The tool made her faster. The process made her safer.

Why waiting is the riskiest move

• Leverage: Early movers compound advantage. Saved hours, reusable prompts, internal precedent libraries. The learning curve pays interest.

• Incentive: Vendors profit from abstraction. Firms profit from hours. Clients profit from outcomes. Only one party signs your review. Align with the client.

• Friction: Approval queues, procurement policies, data access. None of these teach a lawyer to think with a model.

• Ego: “If this is easy, what am I for.” You are for judgment. Tools do not steal that. They surface options so you can decide.

Stop tweaking the tool list. Start transforming the training.

A simple training blueprint that respects legal reality

Week 1: Questions and constraints

• Write three client-style prompts for the same issue, each with a different constraint: time, jurisdiction, audience.

• Compare outputs. Collect what changed and what stayed flat.

• Debrief: what the model is good at, what it misses, what you must supply.

Week 2: Task decomposition

• Break one complex matter into five steps. Assign a model role to each step.

• Use checklists that force verification outside the model for facts and citations.

• Capture reusable prompts in a shared folder with examples and edge cases.

Week 3: Adversarial review

• Stress test your own draft. Ask the model to argue the other side, to find conflicts, to enumerate missing authorities.

• Build a “red team” script you run before any deliverable goes to a client.

Week 4: Decision and client communication

• Use the model to generate options with pros and cons, then write the recommendation yourself.

• Practice a one-page client summary: question, options, recommendation, risk range, next step.

Repeat the cycle on a new matter each month. Measure hours saved and errors prevented. Publish wins internally. Leverage compounds.

Guidelines for safe and effective use

• Sources or it did not happen. Always ask for citations and verify in trusted databases.

• Local facts beat generic answers. Feed the model your context, guard your confidentiality with approved tools.

• One box is not a workflow. Outline, then sections, then critique, then integrate.

• Your name is on the work. The model drafts. You decide.

The close

Legal work is thinking under constraint. Black boxes do not scare me. Untrained thinkers do. The choice is not “trust the model” or “ban the model.” The choice is “train the lawyer to aim the model.” Work backward from the end state. A clear opinion, a tighter memo, a faster path to a decision. Decide, design, deliver.

Subscribe now

Thanks for reading & listening to PossibLaw. We hope you learned something actionable that will help you grow your mind and career. If you enjoyed today’s content please share it. Thank you!

Subscribe now

Takeaways

• Transparency is a leadership superpower: being candid about cash, plans, and thresholds earns trust—even in crises.

• Calibrate risk like a pro: keep “ruinous risk” near zero while building tolerance for everyday variability.

• Customer-obsession wins: ViewExport emerged by listening to CIOs and legal teams struggling with Slack discovery.

• In legal, empathy outperforms escalation: simply hearing the other side often saves time and money.

• Breathe through the tiger brain: “My life is not under threat” is a practical reset for tough moments.

• Multidisciplinary learning compounds—read widely (business, law, psychology, systems) to become more than your title. (Episode discussion throughout.)

• Community beats lone-wolf hustle: add people to your circle who push you out of your comfort zone.

👤 Guest Bio Alex Boyd is a Portland-based entrepreneur and founder building ViewExport, a focused legal tech tool that streamlines Slack e-discovery workflows for IT, security, and law firms. He’s vocal about transparent leadership, practical risk, and staying close to the customer.

🔗 Connect With Alex • LinkedIn: “Alex Boyd” (he’s most active there). https://www.linkedin.com/in/alexcboyd/

🔗 More From Salvador

Our full library of founder & transformation-leader interviews at www.possiblaw.com

Connect with Salvador Carranza on LinkedIn https://www.linkedin.com/in/salvadorcarranza/

Chapters 00:00 Introduction to Entrepreneurship Mindset 04:16 Personal Background and Interests 07:02 The Immigrant Perspective on Risk and Grit 10:02 Navigating the Entrepreneurial Journey 12:54 Understanding Risk Tolerance 15:39 The Importance of First Principles 18:21 Taking Small Steps to Build Confidence 20:58 The Role of Empathy in Leadership 23:33 Navigating Hard Times as an Entrepreneur 36:46 Integrating Grounding Techniques in Legal Practice 38:47 The Importance of Perspective in Legal Challenges 41:12 Continuous Learning and Multidisciplinary Approaches 47:41 Staying Close to Customers in Business 52:54 Building Community and Authentic Connections 01:00:56 Navigating Entrepreneurial Decisions and Opportunities

Share

Thanks for reading & listening to PossibLaw. If you like what you see and hear, I encourage you to subscribe. We are a small team working to help the legal industry grow their entrepreneurial mindset and in turn transform how legal services are delivered to the world. Thank you!

That distinction matters right now, especially in the age of AI and in the legal industry. Change is accelerating. How we research, draft, review, and deliver legal services is shifting under our feet. It is hard. And it’s also the exact kind of hard that makes us better.

Its time for legal professionals to get past the fear, and embrace the future. Its time to choose the hard thing on purpose, remind ourselves we have been augmented professionals for decades and there is a practical playbook for doing it without panic.

Subscribe now

Picture this: whether your a law firm attorney or paralegal or an in-house legal professional, every single day you are feeling overwhelmed with the endless docket of requests for your domaine expertise. Meanwhile every headline says AI will reinvent your job by Tuesday. Your heart rate spikes and palms sweat.

We confuse difficulty with danger. Hard is not hazardous. Hard is how you grow range. In law and in life, the “do hard things” muscle is the only one that compounds. It is also how we model steadiness for colleagues, clients, and yes, the next generation of lawyers who are watching to see whether we panic or lead. So what do you do?

Breathe. Focus. Move forward. Once upon a time finding a legal case meant going to a library and digging into books. You figured out how to master that technology. Then came e-discovery and platforms like Relativity. No problem, you overcame and embraced. Productivity software got added to your requirements along with back end billing and management tools. No big deal, you hunkered down and learned. So why is AI different? It’s not. Embrace the hard thing, embrace the future and shape what’s next.

The Real Constraint Is Not Skill. It Is Story.

Most firms have the skill to learn new tools. They lack the story that makes change feel survivable. Our invisible constraints are narratives like “If I do this wrong, I break privilege,” or “If I get faster, I kill my billables,” or “If I ask for help, I look junior.” Those stories create friction long before any integration or training does.

Here is the reframe I want legal professionals to take in moments that feel existential. Name the work as a hard thing, not a mortal threat. When it is not life or death, your brain reenters the conversation. Breathing returns. Priorities snap into focus. You execute.

Work Backward from the End State

End state: trustworthy legal services that are faster, cheaper, and more humane to deliver. That is the promise of AI if we decide, design, and deliver with intention.

• Leverage: reusable data, repeatable workflows, and a culture of small experiments.

• Incentives: align outcomes so the people who make good choices win, reputationally and economically.

• Friction: shrink the number of steps between a lawyer’s question and a reliable answer, while embracing friction in the right places.

• Ego: give people a way to keep status while they learn in public.

When you organize around these levers, “AI” stops being a mystery project and becomes process improvement with new power tools.

A Scene I Keep Seeing

A mid-size litigation team meets to “figure out AI.” The agenda drifts, tension rises, and someone jokes that we should wait until “the dust settles.” Translation: we are overwhelmed, so we will stall. I ask one question: What would a good week look like if AI helped? Silence, then clarity.

• New matter intake gets triaged in minutes, not hours.

• First drafts arrive as structured outlines that reflect firm templates.

• Privilege screens run by default.

• Partners see risk flags without hunting through email.

Now the game is concrete. We are not debating the future of law. We are deciding how to make next week easier.

Two Mini-Cases

1) In-house legal ops builds an AI intake triage.
The team cataloged their top 20 recurring requests, wrote plain-language decision trees, and connected the trees to an internal chat interface. Results in month one: fewer fire drills, clearer handoffs, and a growing knowledge base. What changed the culture was not the model. It was the rule that no one could reject a draft without suggesting a better one. That reduced ego friction and turned critique into coaching.

2) A boutique employment firm rewrites the billable story.
Partners worried that efficiency would punish them. They switched to blended fees on repeatable work, then published “quality gates” that defined where humans must review. Associates used AI to produce issue maps and citations, then lawyers applied judgment. Revenue held, client satisfaction rose, and attorney stress dropped because “done” became a visible milestone. Incentives finally matched the behavior they wanted.

Share

Why This Matters Now

AI will not replace lawyers who can breathe, focus, and move. It will replace the hours we used to waste proving we were busy. That is good news if we redirect time toward higher-order lawyering: pattern recognition, negotiation, counseling, and strategy. The industry shift is the hard thing in front of us. Our job is to make the right thing easy.

Here are the common blockers I see:

• Approval labyrinths that turn a one-hour pilot into a six-month saga.

• Ownership gaps where everyone wants input and no one wants accountability.

• Tool sprawl that creates ten places to look and zero places to trust.

• Status anxiety that confuses “I do not know yet” with weakness.

None of these are technical. They are human. Name them so you can design around them.

A Simple Operating Rhythm

Use this weekly loop to build “hard-thing reps” without drama.

1. Pick one friction. Choose a single choke point you can measure, like intake time or first-draft latency.

2. Define the end state. Write the two-sentence “good week” description. If you cannot write it, you cannot ship it.

3. Pilot with constraints. One team, one matter type, two weeks. No committees.

4. Set quality gates. Where must a lawyer review, sign, or escalate. Publish it.

5. Close the loop. Capture what worked, update the template, share the win. Repeat.

Strategy → execution → outcomes. Decide, design, deliver.

The Coaching Close

Doing hard things is not theater. It is a quiet habit. When the pace of change spikes, your nervous system screams that the stakes are fatal. They are not. As Alex Boyd reminds us, there is no tiger. So:

• Breathe. Enough oxygen for your brain to come back online.

• Focus. One friction, one end state, one pilot.

• Move. Ship something small that improves a real week for a real team.

That is how you amplify impact in the age of AI. Not by waiting for certainty, but by modeling calm execution when it counts. Hard things are not where excellence goes to die. Hard things are where excellence is built.

Subscribe now

Leave a comment

Thanks for reading & listening to PossibLaw. We hope you learned something actionable that will help you grow your mind and career. If you enjoyed today’s content please share it. Thank you!

Share

You’ll hear practical life lessons on adaptability, culture, and the power of authentic networking, plus how technology, automation, artificial intelligence, and operations. From founder grit to professional development and career advice, this purpose podcast episode hits self development, self help, self improvement, success habits, and what it truly takes to be an entrepreneur and a founder. Whether you’re in law, the broader legal industry, startup mode, or scaling as a leader and balancing priorities, you’ll learn how to start, iterate, and keep going.

Takeaways

• How to give junior talent the mic and build confidence through intentional facilitation.

• Why authenticity beats “polish” and how culture compounds outcomes.

• A repeatable framework for risk assessment (define the downside, set a runway, then act).

• Breaking big goals into actionable steps—learn, try, iterate, ship.

• Private equity 101: what PE does, how operators create value, and common pitfalls.

• The shift to flatter orgs with AI/automation—and how leaders should adapt.

• E-commerce as a numbers game: acquisition, CX, fulfillment, and execution.

• Networking that isn’t “networking”: relationships, curiosity, and service.

• Founder vs. “professional manager” skill sets—and when you need each.

• Career advice: build self-awareness, seek reps, and celebrate small wins.

👤 Guest Bio
Peter is an entrepreneur and operator with experience in corporate consulting, private equity, and building e-commerce businesses in regulated categories. He later joined the board of a publicly traded PetMeds. He’s passionate about team development, technology, and pragmatic leadership.

🔗 Connect With Peter
• LinkedIn: https://www.linkedin.com/in/peter-batushansky-5b67441/

🔗 More From Salvador
• Full library of founder & transformation-leader interviews: www.possiblaw.com
• Connect on LinkedIn: https://www.linkedin.com/in/salvadorcarranza/

👉 If you’re into growing your entrepreneurial mindset, professional development, and learning the success habits that fuel meaningful careers, subscribe so you never miss an episode!

Subscribe now

Chapters

00:00 Introduction to Show

04:58 The Importance of Balance and Networking

08:02 Finding Authenticity and Confidence

10:52 Leadership and Growing Others

13:42 Career Path and Early Experiences

16:48 Transitioning from GE to Private Equity

19:47 Embracing Change and Calculated Risks

28:53 Transitioning to Private Equity

41:02 Understanding Private Equity

49:02 Founding WebEyeCare

50:56 The Role of Founders vs. Professional CEOs

57:55 Navigating the New World of Work

01:04:47 The Power of Consistency in Success

01:06:47 The Journey to Alivet: From Curiosity to Acquisition

01:13:25 Building Relationships and Seizing Opportunities

01:18:46 Navigating Growth and Leadership Challenges

01:21:55 Transitioning Leadership: Finding the Right Fit

01:23:06 Reflecting on the Journey: Lessons Learned

01:23:49 New Horizons: Joining a Public Company Board

01:26:02 Taking Time for Reflection and Future Planning

The next PossibLaw episode drops this weekend and our guest Peter Batushansky hit the nail on the head for everyone trying to become more entrepreneurial. Just try!