Your legal tech app works. Users can log in (you read Part 1, right?). Now they want to upload documents. Contracts. Discovery files. Medical records. The stuff that makes legal tech actually useful.
Where do those files go?
If you vibe-coded your app, there's a decent chance the answer is "somewhere on the server" or "I'm not actually sure." That works fine when it's just you testing things. It stops working the moment you deploy to production or have to answer questions about data security.
Option 1: Local File System
The simplest approach: save files directly to your server's disk. Your vibe-coding session probably generated something like fs.writeFile() or saved uploads to a /uploads folder.
This works for demos. It breaks in production.
Serverless platforms (Vercel, Netlify, most modern hosting) don't have persistent file systems. Your files disappear between deployments. You can't scale horizontally because each server has its own disk. And there's no redundancy. Disk dies, files are gone.
Works for: Local development, quick demos, proof of concepts.
Doesn't work for: Anything deployed to production.
Option 2: Object Storage (S3, R2, Supabase)
The standard solution is object storage. Files go into "buckets" in the cloud, you get back URLs, and the provider handles redundancy and availability.
AWS S3 is the original and still the default. Eleven nines of durability, integrates with everything. The downside: egress fees. Every download costs money. A firm downloading 10TB monthly could see $900+ just in transfer fees.
Cloudflare R2 uses the same S3-compatible API but with zero egress fees. That 10TB monthly download? $0 in transfer costs. R2 is also 20-40% faster thanks to Cloudflare's edge network. The tradeoff is fewer features and a younger ecosystem.
Supabase Storage integrates directly with Supabase's database and auth. If you're already using Supabase, this is the path of least resistance. Files get row-level security tied to your database policies.
Works for: Production applications with straightforward file storage needs.
Watch out for: You're responsible for organizing files, handling permissions, and building document-specific features yourself. And when compliance questions come up, you're on your own.
The Compliance Problem
Here's where legal tech storage gets complicated.
General-purpose object storage gives you a place to put files. It doesn't give you answers when a client's security team sends over a vendor questionnaire.
HIPAA matters the moment you're handling medical records. Personal injury, medical malpractice, workers' comp. If protected health information touches your system, you need a Business Associate Agreement, encryption requirements, access controls, and audit logging. S3 can be configured for HIPAA compliance, but "can be configured" means you're responsible for getting it right.
SOC 2 certification tells enterprise clients that a third party has audited your security practices. Type II means they watched you do it correctly over time. When a BigLaw firm evaluates your tool, SOC 2 often determines whether you make it past the first conversation with their IT security team.
Zero Data Retention (ZDR) matters when AI enters the picture. If your app sends documents through AI models for analysis, clients want to know that data isn't being stored or used for training. The major AI providers offer ZDR options, but you need to configure them correctly and demonstrate compliance.
None of these are impossible with basic object storage. But each requires additional infrastructure, configuration, documentation, and often third-party audits.
Option 3: Legal-Grade Document Infrastructure
Beyond compliance, legal applications have functional requirements that generic storage doesn't address.
Law firms don't just store files. They need to search inside documents. They need OCR for scanned PDFs. They need to know who accessed what and when. They need encryption that satisfies client security questionnaires.
You can build this on top of S3 or R2. Add Textract for OCR, OpenSearch for full-text search, CloudTrail for audit logs. Wire up encryption, access controls, retention policies. Pursue SOC 2 certification. Negotiate BAAs. It's doable. It's also months of work that has nothing to do with what makes your app valuable.
Purpose-built legal document infrastructure handles these requirements out of the box: automatic OCR, semantic search, audit trails, encryption, and compliance certifications. The tradeoff is less flexibility and another vendor relationship.
Works for: Legal applications where documents are core to the product. Apps needing search, OCR, or semantic understanding. Anything where compliance questions need confident answers.
Doesn't work for: If you just need a place to put files and your clients don't ask hard questions about security.
Making Your Decision
Still prototyping? Local file system is fine for now.
Need production storage but documents are just attachments? R2 or Supabase Storage. Pick based on what else you're using.
Dealing with PHI or enterprise clients? You need HIPAA-compliant infrastructure and probably SOC 2 certification. Either build it yourself or find a provider who's already done the work.
Building something where documents are the product? That's where purpose-built infrastructure saves you from rebuilding what every legal tech company needs.
Storage feels like a solved problem until you're three months in and realizing you need full-text search, your OCR integration is flaky, and a client is asking about your SOC 2 status. Pick the right level of infrastructure for where your app is headed, not just where it is today.
Or, skip all of this. case.dev gives you production-ready legal tech infrastructure out of the box, and with Thurgood, our legal-first vibe-coding tool, you can build exactly what you want without worrying about the details. We're here to help you get your app over the finish line. Drop us a line at hello@casemark.com.
This is Part 2 of the "So You Vibe-Coded a Legaltech App?" series. Coming next: Databases, or how to keep track of everything that isn't a file.
