When Lawyers Build Apps

What I learned from reviewing 70+ apps built by legal professionals on Vibecode.law

One of my recent weekend projects was launching Vibecode.law with Chris Bridges and Alex Baker. It’s an open industry platform where legal professionals can learn how to build apps, share what they’ve made, and get inspired by things built by others.

We recently crossed 70 projects on the platform, so I thought now would be a good time to step back from the leaderboard and look at the trends behind what people are building.

Join me on 17-18 June: We are running The Vibeathon, which promises to be the biggest vibecode hackathon in law, at LegalTechTalk in London. This is a unique event, in partnership with HSF Kramer and Replit. You’ll get free Replit Pro credits just for participating, and there are some great prizes on offer. Please don’t forget to register.

Who is building?

62 different people built these 71 projects, and the mix is really interesting. By and large, these are not engineers. The largest identifiable groups are practising lawyers, consultants, legal ops and innovation people, with a handful of students and a couple of GCs.

The takeaway is that most of these are domain experts who taught themselves to build things, not developers who learned some law. Several writeups come from people who describe themselves as non-technical and then mention twelve rounds of security auditing in the next sentence, or admit they were shocked that a feature they assumed was hard had already been done for them. The distance between having an idea and having a working prototype has collapsed.

What are people building?

By studying what people are building, we might get a feel for the problems legal professionals are trying to solve (and which presumably they feel are not already solved by existing commercial applications).

Four categories jump out:

1. Legal Explainers

2. Training Tools

3. Single-Purpose Utilities

4. Research and Drafting Aids

Let’s now take a look at each in more detail.

1. Legal Explainers

The general idea of an explainer app is to take something dense and make it understandable to someone who isn’t legally trained. Some examples:

• Court orders rewritten at an eighth-grade reading level with the deadlines pulled onto a calendar.

• Privacy policies reduced to the few clauses that the data subject needs to know about.

• Rental contracts decoded for students about to sign one.

• Care Act eligibility walked through in plain English, with a letter to the council generated at the end.

All of this goes to making legal information easier to understand. While not every app on Vibecode.law uses AI, most do, and I (personally) think that AI has huge potential to democratise legal information. This has profound implications for access to justice. So, I’m heartened to see that people are building things to help solve this problem.

2. Training Tools

This category is bigger than I expected and it just underlines the growing concern in the profession about how we will train junior lawyers if AI is doing much of the work that juniors have done in the past. Here are some examples:

• A live voice negotiation against an AI counterparty using a firm’s real MSA

• A matter simulator for trainees built inside a large firm

• A tool that plants errors in AI-generated drafts so juniors learn to catch them,

• A card-based recall system for bar study.

I think it’s fair to say that this remains a largely unsolved problem, and I’m looking forward to seeing what people build at The Vibeathon.

3. Single-Purpose Tools

Next up, it’s the small single-purpose tools, which arguably are some of the most useful things on the platform. I like these apps because they typically come from a very specific pain point experienced by the person building the app - and starting from a problem is far better than starting from a solution. Here are some examples of single-purpose tools:

• A tool that unlocks Word documents where track changes has been password-locked.

• A SaaS inflation calculator that pulls live ONS data to compute a contractual uplift.

• A decision-tree builder you can embed in a knowledge base. (Side note: Shoutout to Alex Herrity for bringing this app to life with the UK’s “salmon handling” regulatory framework!)

None of these apps alone will reshape the legal profession. But I think taken together they raise a more interesting possibility - a future in which lawyers don’t just draft documents but actually build solutions to specific problems at the point of need.

4. Research and Drafting

The other submissions fall into the familiar category of research, case search, and drafting. This is the most crowded category, and the one where the established (and well-funded) vendors are perhaps the strongest. Some examples:

• Free Westlaw-style case search

• Citation extraction

• Statute parsers

• Autofill for government forms

• Clause-by-clause contract review.

If anything, I think this category is probably the most interesting to legal tech vendors, because it probably tells them which areas their users feel are mostly unsolved.

Which practice areas?

By practice area, the spread is pretty uneven. Law firm operations is connected to 32 of the 71 projects, then commercial, corporate, regulatory, and technology work. Privacy and data protection, litigation, and IP form a middle tier. Construction, tax, family, and insurance barely register so far.

Perhaps this spread tells us that people feel most comfortable building where (1) they feel the pain themselves and (2) a wrong answer is cheaper. Operations, commercial, and regulatory work is high-volume, more repetitive, and lower-catastrophe when the tool gets something wrong, which is exactly the sort of profile that suits a prototype. The areas that are absent seem to be the ones where the work is bespoke or the cost of error is higher - more on that below.

What aren’t people building yet?

I was also interested to see if there are areas where lawyers aren’t yet building to see if there are untapped opportunities:

First, litigation process coverage is fairly thin. There are plenty of research and case search tools, but very little that helps run a matter through to a hearing: bundling, chronologies, the operational and process side of disputes.

The unglamorous compliance area is missing too. I didn’t see many tools trying to solve for Conflicts, KYC, AML, engagement letters. This work is less exciting to build and harder to test on synthetic data, so perhaps it loses to shinier things that are more fun to build and use. But, in my opinion, there are plenty of unsolved problems in this space.

Access to justice apps shared on the platform are mostly built for the unrepresented person directly, and almost none for the legal aid sector, the law centres, CABs, and duty schemes who serve those people at scale. Nothing wrong with this, but for anyone wanting outsized impact with lower competition, this might be the clearest opening on the board.

The high-stakes regulated area is also mostly empty. I didn’t see much in the way of tax structuring, securities work, clinical negligence. Maybe this is simply because a wrong answer here could be more expensive or dangerous. Interestingly, the tools that do touch higher risk use cases are more careful to frame themselves as preparation before a lawyer gets involved, rather than a substitute.

What about security and compliance?

One of the main reasons we launched Vibecode.law was to bring some balance to the debate on vibecoding. I’d encourage you to check out our Responsible Vibecoding framework.

As a rule of thumb, vibecoded tools are not ready for production rollouts out of the box. In the same way as legal professionals wouldn’t advise their client to vibedraft a Share Purchase Agreement or vibelitigate a dispute, nor should we believe that we can vibecode and maintain a production application without input from a professional.

This isn’t a reason to opt out of building things, but it is a reason to think carefully about who you’re building them for, what data you put into these apps, and how broadly you distribute them.

The vibecode opportunity

As you can probably tell, I am excited about the potential for vibecoding in the legal industry. We are at a moment where anyone can build things and this unlocks huge opportunities.

For legal professionals, we can stop seeing software as something that is done “to” us, and start seeing it as something we can be involved in creating. This doesn’t mean we should vibecode a law firm tech stack overnight, or that we no longer need software engineers, but it does mean we are all now builders, and we can start getting ideas out of our heads and into working prototypes. This is enormously empowering. Let’s just remember our limits and get professional input before we push things more widely.

For vendors, I think it’s time to stop seeing vibecoding as a threat, and start seeing it as an opportunity. How might you open up your platform in such a way that legal professionals can build on top of it? Not only might this make your tool even stickier, but it might help unlock new value or use cases that you hadn’t even considered. (As an aside, there’s rich data on Vibecode.law about what your potential users and customers are already trying to solve for...)

For law students and educators, this opportunity includes you too. I see huge potential for vibecode hackathons in law schools. They’re relatively easy to set up and run (whether or not you have a technical background) and they are probably the best way for students to understand how the underlying technology works. Many of the vibecode platforms now offer free or heavily subsidised credits for educational establishments.

If you do build something, please share it on Vibecode.law. And don’t forget to register for The Vibeathon in June.

Next Up: “The World’s Best Vibecoder is a Lawyer”

In my next post on vibecoding, I’ll share the key takeaways from my discussion with Mike T. Brown, the winner of the global Anthropic/Claude Code Hackathon. In February 2026, Mike saw off competition from 13,000 participants to take home the prize. And he’s a personal injury lawyer who had never written a line of code in his life.