Something interesting happened in legal tech this year. Lawyers started building their own software.
Not hiring agencies. Not filing procurement requests. Opening Cursor or Replit, describing what they want in plain English, and getting a working prototype in a weekend. WashU Law hosted a "vibe coding for lawyers" event. Artificial Lawyer is covering attorneys who build internal tools with AI. Case.Dev launched a legal-tech-specific vibe coding platform in January.
The $4.7 billion vibe coding market isn't just for developers anymore. It's reaching the people who actually understand legal workflows.
And that's genuinely a good thing. The best software ideas in legal tech come from practitioners, not from product managers guessing at what lawyers need. A managing partner who spends 20 hours a week on case intake knows exactly what a case intake tool should do.
The problem isn't the prototype. The problem is what happens next.
Why Lawyers Are Building Their Own Tools (and Why That Impulse Is Correct)
The legal industry spends 4-7% of its budget on technology. That's low compared to most industries. And a huge chunk of that goes to legacy systems that lawyers hate using.
So when a litigation partner discovers she can describe a document review workflow in plain English and get a working tool in two hours, of course she's going to do it. The alternative is submitting an IT request, waiting three months, getting something that doesn't match what she described, and then spending another three months on revisions.
Vibe coding short-circuits all of that. The practitioner goes directly from "I know what this should do" to "I can see it working." That's powerful. It means the person with the domain expertise is also the person specifying the tool.
We've seen this pattern repeatedly. The best legal tech projects we've built started with someone who deeply understood the problem. The worst started with a generic brief from someone two layers removed from the actual users.
So if you're a lawyer who vibecoded a prototype that your team is excited about: you did the hard part. You validated the idea. You proved the workflow makes sense.
Now here's where it gets complicated.
Where Vibecoded Legal Tools Break
Legal tools are different from most software because they handle privileged client data. That's not a theoretical concern. It's a bar obligation. When a vibecoded tool starts handling real case files, real client communications, or real document collections, five things break consistently.
1. No Encryption at Rest
Vibe coding tools generate apps that store data. They don't generate apps that encrypt data at rest using AES-256, manage encryption keys properly, or ensure that a database breach doesn't expose privileged client information. Your vibecoded tool probably stores client names, case details, and uploaded documents in plain text in a database that anyone with server access can read.
2. No Audit Trails
Who accessed the Smith case file at 2:47 AM on Tuesday? A vibecoded tool can't tell you. Production legal software logs every access, every modification, every download, every permission change. Not because it's nice to have, but because when opposing counsel asks during discovery, you need to answer.
3. Flat Permission Models
Most vibecoded tools have two modes: logged in and not logged in. Legal tools need role-based access controls. Partners see everything. Associates see their cases. Paralegals see assigned tasks. Clients see only their own matter. External counsel sees only what you've shared. A flat permission model means a junior associate can access a confidential M&A file they shouldn't know exists.
4. Document Handling Failures
Your prototype uploads and displays PDFs. Great. Now upload 500 PDFs at once. Upload a 50MB contract. Upload a scanned document that needs OCR. Upload a file with the same name as an existing file. Every one of these is a real scenario in legal workflows, and every one will break a vibe-coded file upload component.
5. Search That Doesn't Scale
Your prototype searches 200 test documents in a SQLite database. It feels fast. Put 50,000 real documents in it and watch it crawl. Legal search needs proper search infrastructure with synonym handling for legal terminology, fuzzy matching for misspellings, and relevance ranking that understands legal document structure.
The core issue: None of these are bugs you can fix with another prompt. They're architectural decisions that need to be made before the first line of code is written. Vibe coding tools don't make architectural decisions. They generate features.
What the Bar Rules Require of a Tool You Built Yourself
Everything above is an engineering problem. There's a second set that comes from the rules you work under as a lawyer. Those are harder to spot. A tool can look completely healthy while it's failing every one of them. You find out when somebody asks the system a question it was never built to answer, and that somebody is usually a regulator, opposing counsel, a client wanting their file, or a bar investigator.
Privilege, and what the AI vendor keeps
Privilege covers your communications with clients and your work product. Send that content to a third-party AI service on default terms and the privilege question gets messy fast. ABA Formal Opinion 477R says you have to make reasonable efforts to stop unauthorized people getting at client information. In 2026 that means knowing whether the data you sent is still sitting on somebody's server after the session ends. It also means knowing whether that data can be pulled into discovery or a bar complaint a year later.
Most vibecoded legal tools are wired the way ordinary consumer software is wired. Data goes to the provider, the provider's normal terms apply. For privileged content you want a zero data retention arrangement, which just means the service doesn't keep your content once the session finishes. It's worth being clear about what that gets you, because vendors tend to blur it. Retention is the part you can control. The model still has to read the content in order to answer you, and that happens either way. If a vendor tells you nothing leaves your firm, that's only true when the whole thing runs on your own hardware. Our write-up on on-premise legal AI and the one on privilege tiers go through the trade-offs.
Rule 5.3, and who answers for the output
Model Rule 5.3 says a lawyer has to take reasonable steps to make sure a non-lawyer assistant's work meets the same professional standards the lawyer is held to. Software doing legal work sits inside that rule. If your tool summarizes case documents, suggests arguments, or drafts client emails, you're still the one answerable for what comes out of it.
That has a design consequence. Review by a lawyer has to be built into how the tool works, so it still happens on the evenings when everyone is in a hurry. Picture a tired associate at six in the evening, accepting an AI output with one click, never seeing where it came from. That tool has quietly moved the responsibility somewhere it can't actually be met.
Opinion 512, and telling clients you use AI
ABA Formal Opinion 512, from 2024, is the one written for generative AI. It covers competence, confidentiality, telling clients that you're using AI, and how you bill for it. Put it next to 477R and you get a fairly simple test for anything you built yourself. Can you sit across from a client and explain what your tool does with their information, and can you bill honestly for work a model finished in nine seconds. Both answers need to exist before the thing touches a live matter. We went through what 512 means for a law firm chatbot in more detail. If you practise in Canada, the Law Society of Ontario has its own version of the guidance.
Summaries that can't show their work
A tool that summarizes a 200-page contract or a stack of medical records has to point at the exact passage, on the exact page, behind every claim it makes. Without that, the lawyer has to go back and read the source to check the summary. That costs more time than the summary saved. It also makes the Rule 5.3 obligation above impossible to meet in practice. It's the most common gap we find in chronology and summarization tools. It's also the one you can't prompt your way out of. If the citations were never captured while the document was being processed, they don't exist to be shown later.
Deadlines, and real court rules
A deadline feature built from a founder's memory of how court rules work will get a firm into trouble eventually. Real deadline logic has to handle several things at once. Filing windows that differ by jurisdiction, federal holidays, cutoff times for electronic filing in the right timezone, and the confirmation trail showing a filing actually arrived. If the prototype stores a limitation date as an ordinary date field and the deadline slips by a day, you're in malpractice territory. Fixing it means changing how the tool handles time all the way through, which is why patching it on top so rarely holds.
Getting one client's data back out
A tool built for one client's matters gets stretched to cover a second. What you end up with is usually a data model where the separation lives in somebody's head and nowhere in the database. That holds up fine until the first client ends the engagement and asks for their complete file. Now the tool has to hand over one client's data and only that client's data, and it can't do it cleanly. Nobody builds a demo around the day a client leaves, so this one tends to survive all the way into production.
Worth noticing: everything in this section stays invisible while the tool is working normally, which is how it all survives so long. It surfaces at the worst possible moment, and by then the honest answer is that the system was never built to answer the question being asked.
The 80/20 Problem: What Vibe Coding Gets Right and What It Misses
Vibe coding is genuinely good at the first 80% of a product. UI layouts. Basic CRUD operations. Form handling. Navigation. Connecting screens together. For an internal tool that three people use to track deadlines, that 80% might be enough.
The remaining 20% is where production-ready legal tech lives. And that 20% accounts for about 80% of the actual engineering work.
| Vibe Coding Handles Well | Requires Production Engineering |
|---|---|
| UI layout and design | Encryption at rest and in transit |
| Basic form handling | Comprehensive audit trails |
| Simple data display | Role-based access controls (RBAC) |
| Page navigation | Search infrastructure at scale |
| Basic authentication | Secure document handling (50MB+ files) |
| Connecting to APIs | Error handling for edge cases |
Research backs this up. AI-generated code has 1.7x more major issues than human-written code. And vibe-coded projects typically hit a complexity ceiling around 15-20 components. Beyond that, the AI starts contradicting its own earlier decisions, introducing bugs that cascade through the system.
For a legal document management tool, 15 components gets you about as far as: login, dashboard, document list, document viewer, upload form, search bar, and a settings page. That's a demo. It's not a platform your firm can rely on.
What Production-Ready Legal Tech Actually Requires
Here's the non-negotiable infrastructure that separates a prototype from a platform your firm can trust with client data.
Search Infrastructure
If your tool involves searching across documents, case files, or any corpus larger than a few hundred records, you need dedicated search infrastructure. We use Elasticsearch with custom analyzers built for legal terminology. Synonym dictionaries that understand "breach of contract" and "contract breach" are the same concept. N-gram tokenizers that handle partial matches. Relevance boosting that surfaces the most important documents first.
We've built this legal document search architecture three times for different clients. The pattern is proven: 100ms query times on 100,000+ documents, autocomplete, search history, and usage analytics via Kibana.
Role-Based Access Controls
Not "admin and user." Real RBAC with granular permissions per role, per resource, per action. In legal tech, this means matter-level access controls where a user can see Case A but not Case B, even though they have the same role title. It means ethical walls between practice groups. It means temporary access grants for external counsel that expire automatically.
Encryption and Data Protection
AES-256 encryption at rest. TLS 1.2+ in transit. Encrypted document storage on S3 with per-document access logging. Key rotation policies. Zero-PHI email patterns if your tool touches health-related legal data. This isn't a feature list. It's the minimum bar for handling privileged information.
Audit Trails
Every data access, every modification, every permission change, every login, every failed login attempt. Timestamped, immutable, queryable. We've written a detailed guide on audit trail implementation that covers the architecture. The short version: if you can't produce a complete access log for any record at any time, your tool isn't ready for client data.
Real Examples: What We've Built and What It Took
These are production legal tech platforms we've delivered. Not prototypes. Finished products handling real client data. You can see the full cost breakdown in our pricing guide.
Legal Document Search Platform
The problem: A legal services firm needed 100,000+ documents searchable with the precision lawyers expect. Not keyword matching. Exact phrase search, synonym recognition, fuzzy matching, autocomplete.
What we built:
- Elasticsearch with custom legal analyzers and synonym dictionaries
- N-gram tokenizers for partial matching
- Autocomplete with relevance boosting
- Search history, favorites, and recently added documents
- Usage analytics via Kibana
- AWS deployment for high availability
Timeline: 8-10 weeks
Result: 100ms query times. $220K+/year recovered in search time savings.
We've built this exact architecture three times for different legal use cases. A vibe-coded version would handle the UI. It wouldn't handle the Elasticsearch cluster configuration, the custom analyzers, the synonym dictionaries, or the relevance tuning that makes the difference between "search that kind of works" and "search that lawyers actually trust."
Legal Case Management Platform
The problem: HIPAA-compliant case management with three distinct user portals, encrypted document handling, and secure per-case messaging.
What we built:
- Client portal: registration, multi-step case submission, document upload, status tracking
- Broker portal: case dashboard, tabbed views, internal notes, file management
- Admin portal: full oversight, user management, audit log viewer
- HIPAA compliance: S3 encryption, RBAC, audit trails, zero-PHI emails
- Reusable component library for future development
Timeline: 290 hours across 8 weeks. 3-role RBAC.
This is the kind of project that's impossible to vibe code. Three separate portal experiences, each with their own permission boundaries, talking to the same database through different access layers. The prototype might look similar on the surface. Underneath, every data access goes through an authorization layer, every action is logged, and every document is encrypted.
Structured Settlement Platform
The problem: A legal services startup needed an MVP to prove their business model, fast. Secure case intake, document management, HIPAA compliance.
What we built:
- Secure client and broker portals
- Document upload with encryption
- Case tracking workflow
- HIPAA-compliant infrastructure
- Informational marketing website
Timeline: $15K. 5 weeks.
Result: Client secured a $2,000/month retainer customer within weeks of launch.
This is the closest analog to a vibe-coded prototype going to production. The founder knew exactly what they needed. We built it with proper compliance from day one instead of trying to bolt it on later. Five weeks. $15K. Production-ready with real revenue on day one.
The Path from Prototype to Production
If you have a vibecoded legal tool that your team is excited about, here's the realistic path to making it production-ready. Not the code. The idea, the validated workflows, and the UI patterns your team already likes.
Step 1: Audit the Prototype (Week 1)
Walk through every screen, every workflow, every data flow. Identify what's working as a feature, what's missing from a compliance perspective, and what needs to change architecturally. The prototype is your spec document, not your codebase.
Step 2: Architecture and Foundation (Weeks 2-3)
Build the infrastructure the prototype doesn't have: authentication, RBAC, encryption, audit trail architecture, database schema designed for the actual data model. This is the foundation everything else sits on. Shortcuts here create compounding problems.
Step 3: Rebuild Features on the Foundation (Weeks 4-7)
Recreate the prototype's features on top of the production architecture. This goes faster than you'd expect because the prototype already answered the hard questions: what the UI should look like, what the workflows are, what data needs to move where. You're not designing. You're implementing a validated design on a proper foundation.
Step 4: Compliance Verification (Weeks 8-9)
Security testing. Penetration testing if the scope warrants it. Verify encryption is working at every layer. Test RBAC boundaries. Confirm audit trails capture everything they need to. If HIPAA applies, complete the risk assessment documentation.
Step 5: Deploy and Monitor (Week 10)
Production deployment on infrastructure configured for security and availability. Monitoring for errors, performance, and unusual access patterns. Runbooks for the team on how to handle incidents.
Timeline reality check: 6-10 weeks with a team that's built legal tech before. 4-6 months with a team learning compliance requirements on the job. The prototype you already built saves 2-4 weeks of discovery and design that would otherwise happen at the start of the project.
Frequently Asked Questions
Does running client data through an AI model in my own tool waive attorney-client privilege?
Using AI does not waive privilege on its own. How the tool is configured is what decides it. ABA Formal Opinion 477R says you have to make reasonable efforts to stop unauthorized people getting at client information, which in practice means knowing whether the data you sent to an AI service is still stored after the session ends. A zero data retention arrangement means the service does not keep your content once the session finishes. Be clear about what that gets you: retention is the part you control, and the model still has to read the content in order to answer you. If a vendor says nothing leaves your firm, that is only true when the whole thing runs on your own hardware.
What do ABA Opinions 512 and 477R require if I built my own AI legal tool?
Opinion 477R covers securing client information, and Opinion 512 (2024) covers generative AI specifically: competence, confidentiality, communicating with clients about AI use, and fees. Together they give you a fairly simple test for a tool you built yourself. You have to be able to explain to a client what the tool does with their information, and bill honestly for work a model finished in seconds. Model Rule 5.3 adds a third requirement. Software doing legal work falls under the supervision obligation, so review by a lawyer has to be built into how the tool works, and every output has to trace back to a source someone can check.
Why can't a vibe-coded deadline tracker be trusted with real court deadlines?
Because prototypes store a deadline as an ordinary date field. Real deadline logic has to handle several things at once. Filing windows that differ by jurisdiction, federal holidays, cutoff times for electronic filing in the right timezone, and the confirmation trail showing a filing actually arrived. If a limitation date slips by a day, you are in malpractice territory. Fixing it means changing how the tool handles time all the way through, which is why patching it on top so rarely holds.
Can lawyers actually build usable software with vibe coding?
Yes, for validation and internal prototypes. Vibe coding tools let lawyers build working demos that prove a workflow idea has value. The limitation is production readiness: AI-generated code has 1.7x more major issues, and projects hit a complexity ceiling around 15-20 components. For anything handling privileged client data, you need proper security, audit trails, and access controls that vibe coding tools don't generate.
What breaks when a vibe-coded legal tool goes to production?
Five things consistently: no encryption at rest for client data, no audit trails, flat permission models instead of RBAC, no error handling for document processing edge cases, and search that fails at scale. These aren't cosmetic issues. They're liability risks for any firm handling privileged information.
How much does it cost to take a vibe-coded prototype to production?
$17,000-$53,000 depending on scope and compliance requirements. A simple tool with 2 roles and basic compliance runs $17K-$26K in 5-8 weeks. A platform with search infrastructure, 3+ roles, and HIPAA compliance runs $35K-$53K in 8-12 weeks. The prototype's code usually isn't salvageable, but it's invaluable as a specification.
Should we keep the prototype's code or rebuild?
Almost always rebuild. The prototype's value is the validated idea and UI patterns, not the code. AI-generated code lacks proper architecture, has no test coverage, and wasn't built with compliance in mind. Rebuilding on a proper foundation takes 6-10 weeks. Patching a vibe-coded codebase into compliance takes longer and costs more.
What compliance requirements apply to legal tech tools?
At minimum: encryption at rest and in transit (AES-256, TLS 1.2+), audit trails logging every data access and modification, RBAC separating user types, secure document storage with access logging, and session management with automatic timeouts. If the tool touches health-related legal data, HIPAA requirements also apply. None of this is optional for privileged information.
How long does it take to go from prototype to production?
6-10 weeks with a team experienced in legal tech. Week 1: audit and architecture. Weeks 2-3: foundation (auth, RBAC, encryption, audit trails). Weeks 4-7: feature rebuild. Weeks 8-9: compliance verification. Week 10: deploy. Teams without legal tech experience take 4-6 months because they learn compliance requirements while building.
Your Prototype Proved the Idea. Let's Make It Real.
If you've vibecoded a legal tool that your team actually uses, you've already done the hardest part of software development: proving the idea works. You know the workflows. You know the pain points. You have a working demo that shows what the product should do.
We take validated prototypes and rebuild them as production-ready legal tech with the compliance, security, and infrastructure they need to handle real client data. If your prototype is hitting walls with security, scale, or reliability, our vibe code rescue service is built for exactly this situation.
We've built legal document search platforms, case management systems, and compliance tools. 5-12 weeks, production-ready, compliance built in from day one.
Have a prototype that needs production hardening?
30-minute call. Show us what you've built. We'll tell you what it takes to make it production-ready.
Book a Prototype Review