How Much Does It Cost to Rebuild a SaaS Tool With AI?
Rebuilding a $50/month SaaS tool with AI takes days, but maintenance, security flaws, and architecture debt add costs. Here is the real math on build vs buy.
How much does it cost to rebuild a SaaS tool with AI?
Rebuilding a $50/month SaaS tool with AI is fast now. A small team using Cursor, Claude Code, or Retool can rebuild the narrow slice of functionality they actually use in days, not months. What AI can't shrink is the cost of running what it built: the security patches, the edge cases, the architectural debt that piles up the moment the demo ends and real users show up. The gap between "it works" and "we can run this safely forever" is the whole story.
TL;DR
- AI makes initial scaffolding fast, but it struggles with edge cases, security, and maintenance, so the last stretch of work does not move at AI speed.
- Rebuilding a SaaS tool creates permanent internal maintenance costs that can erase the initial savings.
- Veracode found that 45% of AI-generated code samples contained security flaws, which turns an unreviewed internal tool into unmanaged shadow IT.
- The successful rebuilds, including CarboNet, Harmonic, and Dave Clark's CRM, all targeted narrow, specific workflows rather than entire platforms.
- CarboNet's roughly $5,000-a-year maintenance estimate shows that the build cost is a one-time number while the maintenance cost is recurring.
- AI-built tools work best for small teams with low-compliance workflows, because once audit trails, versioning, or access control matter, the enterprise vendor's features earn their price again.
What did we set out to rebuild in the experiment?
We picked a target the way most teams actually do: not a strategic system, but an annoying $50-a-month tool that one team uses for one job. A lightweight CRM view. A status dashboard. The kind of thing nobody remembers approving in procurement.
The rules were simple: no human-written code, only AI-generated output through prompting and review, time-boxed to a few working days, not weeks. We scoped it the way companies that actually do this scope it: not "rebuild Salesforce," but "rebuild the three screens of Salesforce this team opens every day." That distinction matters. Dave Clark, the former CEO of Amazon's consumer operations, vibe-coded a CRM replacement for his startup Auger over a single weekend. What made it possible wasn't raw AI horsepower, it was that off-the-shelf tools had too many fields his team never used. He wasn't rebuilding CRM. He was rebuilding his CRM.
Why does this question matter now?
This isn't an academic exercise. The average company now spends roughly $4,830 per employee per year on SaaS, up sharply year over year, and runs an average of 275 separate SaaS applications. Nearly half of those licenses sit underused or unused. That's the math every finance leader is staring at, and it's why "can we just build this ourselves" moved from an engineering joke to a line item on a budget review.
It's also why the examples keep piling up. CarboNet, a 65-person company, built a custom CRM for roughly $15,000 to $20,000 working with a vibe-coding vendor. Harmonic's automation team rebuilt a tool that was costing them about $20,000 a year inside Retool, after support delays made rebuilding faster than waiting for a fix. Cisco says it saved nearly $5 million a year in license costs by replacing a presentation tool with an internal AI agent, and it's evaluating doing the same to vendors that cost $50 million to $200 million annually. The pattern across every one of these cases: narrow scope, specific pain, fast build. None of them tried to rebuild an entire category of enterprise software from scratch, and that distinction is the hinge the rest of this piece turns on. If you want the step-by-step mechanics of this kind of build, we've walked through the actual workflow before.
What happens from day one to done when building the replacement?
The part everyone expects AI to be good at, it's good at. CRUD screens, basic auth, a serviceable UI, a working data model: all of that comes together fast. Harmonic describes the same experience: their team now files five AI-generated tickets for every human-filed one, and has shipped 33 internal apps using the same muscle. CarboNet had the same experience. So did Dave Clark, over one weekend.
But treat that speed as a universal truth about AI productivity and you'll get burned. A randomized controlled trial from METR tested experienced open-source developers using early-2025 AI coding tools on real tasks and found they took 19% longer than working without AI, despite believing the whole time they were faster. The lesson isn't that AI makes you slower. It's that the speedup is real for what AI is actually good at, CRUD and scaffolding, and illusory or negative for everything else: debugging someone else's generated code, untangling a dependency, deciding whether an edge case even matters. Our build felt exactly like this. The first eighty percent of functionality showed up almost immediately. The last five percent, the part that actually makes a tool production-ready, did not move at AI speed at all.
Where Does AI-Generated Code Actually Break?
"Working" and "production-ready" are different claims, and AI-generated code tends to satisfy the first one much more reliably than the second.
The security picture alone should give any team pause before shipping an AI-built internal tool to anyone outside the person who prompted it:
- Security flaws are common, not rare. Veracode found that 45% of AI-generated code samples contained security flaws. A separate large-scale analysis of public GitHub repositories cuts the other way, 87.9% of AI-generated code carried no identifiable CWE-mapped vulnerability, but the remaining gap was language-specific and real: Python code showed vulnerability rates of roughly 16% to 18.5%, well above JavaScript or TypeScript.
- Code quality erodes with scale and speed. GitClear's analysis of 211 million lines of changed code between 2020 and 2024 found an eightfold increase in duplicated code blocks during 2024, and refactoring dropped from 25% of changed lines in 2021 to under 10% in 2024. That's a codebase getting less maintainable even as it gets built faster.
- Speed and architecture quality move in opposite directions. When Cursor used a swarm of AI agents to build FastRender, a browser engine, in one week, roughly equivalent to 110 person-years of development effort, independent auditors scored it 1.3 out of 5 for maintainability and 2.1 out of 5 for architecture quality.
None of this means the AI-built tool doesn't work on day one. It means the bill for how it was built comes due later, in a form nobody budgeted for.
How Much Does It Cost to Maintain an AI-Rebuilt SaaS Tool?
Here's the number that should anchor every build-vs-buy conversation about AI-rebuilt SaaS: CarboNet spent $15,000 to $20,000 building its custom CRM, and now estimates maintenance at about $5,000 a year. That's not nothing, but it's a fraction of a comparable SaaS contract, and it shows the real shape of the trade. The build cost is a one-time number. The maintenance cost is recurring, and it never fully goes away, because the thing you built doesn't have a vendor's engineering team patching it in the background. You do.
A LinkedIn critique from Konstantin Ristl frames this bluntly: when a team builds instead of buys for a non-core function, it isn't building a tool once, it's becoming the permanent IT admin for a shadow product. Avoiding a $100-a-month subscription can quietly burn thousands of dollars of a team's own engineering time in patching, feature requests, and undocumented onboarding. That's the real line item this whole category of experiment tends to hide. We've written before about the actual math behind building versus buying internal tools, and the maintenance tail is exactly where that math gets honest, or stops being honest.
What do the skeptics get right (and wrong)?
The loudest counter-case is Klarna. Its CEO, Sebastian Siemiatkowski, confirmed the company shut down roughly 1,200 SaaS tools, Salesforce included, after building internal AI and knowledge systems with Cursor. But he walked the claim back from where the headlines took it: Klarna "did not replace SaaS with an LLM," and enterprise software's audit trails, versioning, and access management still had real value they had to account for. That caveat does more work than the viral version of the story suggests.
MIT's GenAI Divide research backs up the caution. Pilots built through strategic vendor partnerships reach full deployment about 66% of the time, versus roughly 33% for internally built AI projects, and 95% of generative AI pilots overall show no measurable P&L impact. Large enterprises seem to have absorbed this lesson already: FedEx, Grant Thornton, and EY all describe vibe-coding small customizations on top of their core systems, not ripping out ERPs or CRMs. Stay SaaSy's "Bob the CTO" critique captures the arithmetic skeptics should keep in mind: a team dedicating $400,000 of headcount to replace $200,000 of SaaS tooling isn't saving money, it's reallocating a bigger budget to a riskier line item, and that trade only makes sense at FAANG scale or when the replacement is genuinely spreadsheet-simple.
When Should You Rebuild a SaaS Tool with AI Instead of Buying It?
After running the build and reading the comparables, the pattern separating the successes from the cautionary tales isn't the tool. It's the shape of the problem:
- Scope is narrow and well understood. You're replacing three screens someone opens daily, not an entire platform. CarboNet, Harmonic, and Dave Clark all stayed inside this lane.
- The team is small enough that one person can own it. If the tool needs a dedicated maintainer from day one, the math already looks like Stay SaaSy's Bob problem.
- The workflow isn't regulated or audit-heavy. Klarna's own walk-back is the tell here: the moment compliance, versioning, or access control matter, the enterprise vendor's boring features start earning their price again.
- The team actually wants to own the maintenance tab. CarboNet's $5,000-a-year figure is the honest cost of ownership, not the sales pitch version. If nobody wants that job, don't build the tool.
- The SaaS vendor is genuinely slow or expensive relative to the fix. Harmonic rebuilt because support was too slow to be useful, not because rebuilding was free.
| Upfront Cost | Ongoing Maintenance Burden | Security Risk | Audit/Compliance Fit | Speed to Launch | |
|---|---|---|---|---|---|
| Build In-House with AInarrow, well-understood workflows with no compliance exposure | Days of prompting | High | High | Low | High |
| Buy / Keep SaaS Subscriptionregulated, audit-heavy, or broadly shared workflows | Recurring subscription fee | Low | Low | High | Medium |
We've built out this logic into a fuller four-question framework for build-versus-buy decisions elsewhere, and it holds up here: the AI doesn't change whether you should own this software, it changes how cheaply you can find out.
Who owns what you just built under shadow AI and governance?
The tool we built here is, by definition, shadow IT. Nobody filed a procurement ticket. No security team reviewed it. If it had leaked a customer record because of one of the vulnerability classes Veracode and the GitHub analysis both flagged, there'd be no vendor SLA to point to, just whoever typed the prompts. That's the governance question most teams skip past in the excitement of a working prototype: who inherits this when the builder leaves, and who's accountable when it breaks. Treat anything you build this way with the same seriousness you'd apply to a vendor contract. The moment it touches real data, that's exactly what it has become, whether or not anyone signed anything.
Frequently Asked Questions
Can AI really rebuild a $50/month SaaS tool in a few days?
For a narrow slice of functionality, yes. CRUD screens, basic auth, and simple dashboards come together fast with tools like Cursor and Retool, as shown by CarboNet's custom CRM build and Dave Clark's weekend CRM rebuild for Auger. The speed drops sharply once you move past the core 80% into edge cases, integrations, and security hardening.
Is AI-generated code safe to run in production?
Not automatically. Veracode's testing found 45% of AI-generated code samples contained security flaws, and a separate GitHub-based analysis found Python code in particular carried vulnerability rates of 16% to 18.5%. AI-generated code needs the same security review as any other code before it touches real customer data.
What does it actually cost to maintain an AI-built internal tool?
Often more than the build itself over time. CarboNet spent roughly $15,000 to $20,000 building its custom CRM but estimates about $5,000 a year to keep it running. The ongoing cost is patching, feature requests, and informal support that would otherwise be the vendor's job, which is why critics describe the builder as becoming a permanent IT admin for a shadow product.
Did Klarna actually replace Salesforce with AI?
Klarna shut down roughly 1,200 SaaS tools, including Salesforce, after building internal AI and knowledge systems with Cursor. But CEO Sebastian Siemiatkowski later clarified that Klarna did not replace SaaS with an LLM, and that enterprise software's audit trails, versioning, and access controls still had real value the company had to account for.
When should a team buy SaaS instead of rebuilding it with AI?
Keep paying when the workflow is regulated or audit-heavy, when no one on the team wants to own ongoing maintenance, or when the build would require headcount that costs more than the subscription itself. MIT's research found internally built AI pilots reach full deployment only about 33% of the time, versus 66% for vendor-partnered pilots, which argues for caution outside narrow, well-understood use cases.
How we source, write, and correct our articles. Editorial standards
