Vibecoding your way out of expensive legaltech
How GenAI changes the $-math for SaaS
Newsletter #20
Hang around for some info on how to save some dolla dolla billz
A word from the person behind the laptop
Around three months ago legend Andrej Karpathy posted a tweet about “vibecoding”.
I had seen the word used before but this is definitely the breakthrough moment for the term which seems to have turned into a full-blown movement.
It seems like people didn’t really have the words to express what they we’re doing when they we’re building software using only ChatGPT or other solutions like Replit, Cursor or Loveable.
I’ve been an amateur developer for years: building half-functional apps in Python, tinkering with Swift, and generally wasting weekends on side projects that mostly didn’t work very well. But now? I literally vibecoded a Swift application with one prompt that took me 3-months to built back in 2015.
Replit CEO Amjad Masad says 75 % of its users never write a single line of code and Gartner assumes that by 2026, around three-quarters of all new applications are built low-code technologies.
How do you feel about CJEU vibedrafting?
This obviously raises the question: If company X is paying vendor Y mid-six figures a year for a SaaS licence, does that still beat rolling out own internal tools if they’re that easy to build?
Unfortunately, the math isn’t that straightforward.
In this post we’ll dig into why. Hang tight!
“Sorry, we’re building this internally”
Back when my own start‑up was still pitching its very first pilots, we kept hitting the same polite brick wall:
“Love the demo, but why wouldn’t we just use ChatGPT?”
and/or
“Love the demo, but we’ll just spin up something ourselves.”
Vibecoding your way to save time by not dealing with external vendors
Things are moving fairly quickly at the moment and companies are probably just figuring out where AI actually adds value. In that context, onboarding a new shiny AI solution might seem like a stretch (even though our solution is of course the best in the market).
We work in a sector where people can be famously risk-averse (for good reasons). So building something internally with people that understand the internal processes, systems and data might seem like a safe bet on the surface. Especially now that you can build internal software over your lunch break accompaigned by a chatbot.
But here’s where things get messier.
Just because you can build an app internally doesn’t mean you can support it. And if your legal department doesn’t have budget for maintenance, evaluations, security, or any of the other “boring” siblings of vibecoding, then you're not building software. You’re stacking technical debt.
According to Stripe’s Developer Coefficient study:
(..)the average developer spends more than 17 hours a week dealing with maintenance issues, such as debugging and refactoring. In addition, they spend approximately four hours a week on “bad code”, which equates to nearly $85 billion worldwide in opportunity cost lost annually(..)
Truth is that many vibecoders don’t even know what maintenance and refactoring is. That’s 42% of the workweek not spent on shiny new features, but on keeping the lights on.
Stats from Stripe’s Developer Coefficient
If legal departments are already struggling to squeeze value from tools they already bought then getting the budget to vibecode your departments way into the future might even be even more far fetched.
“Good enough” doesn’t scale
Sometimes, the DIY approach makes perfect sense.
I can install a new kitchen using nothing but YouTube tutorials. It won’t look like something out of Architectural Digest, but since it’s just my wife and I looking at it 98% of the time, we can probably live with a crooked drawer for a while. At least until we get around to fixing it.
But that doesn’t mean I’m qualified to build an industrial kitchen for a high-end restaurant in Copenhagen. If I did, it might affect more than just aesthetics. It could impact the quality of the food, the restaurant’s business, and possibly Copenhagen’s culinary reputation (RIP Noma).
Same goes for software.
I can easily build a simple “rental contract checker” using GPT and a bit of logic. It works well enough as a first pass. I’ll still review it, of course, but as a personal productivity tool? Totally fine.
But that doesn’t mean I should roll it out across an enterprise, where hundreds of rental agreements (and maybe entire deal structures) depend on the standards baked into the equivalent of a weekend project. Especially not if I, as a lawyer, have no plans (or budget) to maintain the tool once it’s in production.
Because at that point, we’re no longer talking about a helpful side project. We’re talking about infrastructure. And "good enough" doesn’t scale when real risk is involved.
Imagine if someone wrote contracts like that. Your job as a lawyer would be insufferable, looking through other peoples bullshit contracts. This is probably how many developers feel at the moment.
…and it might not even be worth it
Let’s say you did it. You vibecoded a working prototype. It parses contracts, updates your matter tracker, even pretends to understand your internal folder structure. The team loves it. Legalops is impressed. You’re a genius - and you might even feel like a real developer!
But unless you plan to freeze time at the prototype stage, things get expensive very quickly. So let’s talk a bit about the thing we’re all thinking about: the cost
The fantasy is that building internally is cheaper. “Look how quickly we deployed this tool!” Unfortunately, the fantasy ends somewhere between your third code refactor and your first security audit.
I made a back-of-the-envelope calculation to show that the numbers are actually fairly easy to put together (I’m not a math guy btw, but I did my best):
Danish developer salary would make the calculation even worse for the internal build projection so I used Germany as an example. Still doesn’t hold water though.
This is only year one, but break-even with SaaS might not until year 3 or 4. And that’s assuming nothing breaks, no regulations change (EU, hahahaha), and no developer rage-quits because they were on call during Christmas or people in the department keep talking about how useless developers are now that we can vibecode.
Meanwhile, vendors amortise the boring parts. Ironclad’s 2023 Forrester TEI study shows a 314% ROI over three years after factoring in licence fees, onboarding, and support. I haven’t double checked these numbers, but if that’s the math your DIY project is up against then… good luck.
Then what can we use vibecoding for? It’s magic for proof-of-concepts and throwaway workflows. It’s fun, fast, and often useful. But once you’re maintaining real infrastructure, dealing with 42% of your week spent on upkeep, plus the 60% lifecycle cost that hides in patches, bugs, and mystery downtime the economics flip. So the initial idea of keeping it in-house to save money might fall short.
Unless you're building something that's actual firm IP, something you’d never hand to a vendor on principle, cut the RFP short, pay the invoice, and let someone else answer the 3 a.m. pager.
Start-up of the week(ish)
I’ve got a lot of faith in voice assistants for legal. Not just because I’ve seen Boomer lawyers still rocking dictaphones, but because speaking out loud is actually a solid way to organise your thoughts.
LexisNexis kicked off Legalweek by launching Protégé’s new voice AI assistant in the U.S. Allegedly the first in legal? Not sure about this - but now instead of typing prompts, you can just talk to your research assistant.
Extra toppings
The goalposts for what AGI is are shifting from week to week. This is only 3 years ago:
LLMs for LL.Ms: practical observations on AI, law, and building legal technology. Roughly twice a month.
Originally published on Substack →







