In the last few months, a few customers cancelled their ProBackup subscription with the same reason: "we vibe coded our own backup tool." Recently, one of them came back. Their homegrown tool had been failing silently for weeks, and they only found out when they actually needed it.
We get the appeal, genuinely. Prompt Lovable or Claude to "build a tool that backs up our ClickUp workspace every night" and twenty minutes later it works. The data lands in a bucket, the cron job runs, and the internal Slack message writes itself: we just saved ourselves a SaaS subscription. But a backup tool is the one piece of software in your stack that only matters on its worst day, and a vibe-coded backup has usually never seen a worst day. This post covers what vibe coding platforms do brilliantly, the specific risks of pointing them at business-critical data protection, and an honest cost comparison between building and buying. The short answer to the question in the title: the danger isn't that AI writes bad code. It's that nobody ever tests the restore.
Vibe coding platforms are genuinely impressive
Let's start with credit where it's due, because this isn't a "AI code bad" post.
Vibe coding, the practice of describing what you want in natural language and letting an AI agent write the software, has matured fast. Lovable's Agent can now browse websites, search the web, and update code across multiple files at once, acting more like a developer working alongside you than an autocomplete. In May 2026 Lovable added AI subagents, including a Reviewer, that run in parallel during a build, and the platform now ships native Wiz security scanning, with findings surfacing in every project's Security view. In July 2026 Lovable became the first AI coding platform to achieve AIUC-1, a security and reliability standard built for AI agents.
That's real progress, and the productivity gains are real too. For internal dashboards, prototypes, landing pages, and yes, your personal note-taking app, these tools are hard to beat. The question is not whether vibe coding works. It's whether a backup tool is the right thing to vibe code.
Key takeaway:
Why backup tools are a special case
A backup tool has an unusual property: it can fail silently for months and look completely healthy. The cron job runs. The files appear. Nobody opens them. Then someone deletes a ClickUp space, or an AI agent overwrites two thousand HubSpot records, and you discover that your "backup" has been saving empty API responses since the ClickUp API changed in March.
Under the shared responsibility model (the standard SaaS arrangement where the vendor protects the platform, but you are responsible for your own account data), that gap is yours to own. If your homegrown tool quietly broke, there is no vendor to call.
The known risks of vibe coding, applied to backups
The research on AI-generated code is no longer anecdotal. Here's what it says, and what each finding means when the code in question is guarding your data.
- More vulnerabilities, shipped faster. Veracode's 2025 code security report found AI-assisted pull requests generated 2.74 times more security issues than human-authored code, and a 2026 GitGuardian report found AI-assisted commits exposed secrets, such as API keys, more than twice as often as human-only commits. A backup tool holds admin-level API tokens for your most important systems. A leaked token isn't a bug; it's a master key.
- Hallucinated dependencies. A Cloud Security Alliance research note from April 2026 found that across 2.23 million AI-generated code samples, 19.7% contained at least one hallucinated package name, and 43% of those names reappeared consistently on repeated runs. Attackers register those predictable names, a technique called slopsquatting. Install one, and your backup pipeline is running someone else's code against your production data.
- Incidents are now on the record. Georgia Tech's Vibe Security Radar, which traces CVEs back to AI-generated code, attributed 35 CVEs to AI coding tools in March 2026 alone, up from 6 in January. This has moved from thought experiment to vulnerability database.
- Nobody maintains it. This is the quiet killer. The person who prompted the tool into existence changes roles, and the "codebase" is a chat history nobody else can reason about. Meanwhile the platforms it connects to keep moving.
- The restore is never tested. Copying data out is the easy half. Putting it back, with hierarchy, relationships, comments, custom fields, and permissions intact, is the hard half, and it's the half a weekend build almost never includes. A backup you can't restore from is a storage bill.
- False confidence. The most dangerous property of vibe-coded software is that it looks finished. It demos well. The one scenario that would expose it, a real disaster, is the one scenario you can't rehearse by accident.
What a dedicated backup vendor actually does all day
This is the part that's invisible from outside, so it's worth spelling out what that subscription pays for at ProBackup:
Continuous integration maintenance. We back up nine platforms, and right now every one of them is rolling out features and API changes at the fastest pace we've seen. When ClickUp adds a new field type or HubSpot versions an endpoint, updating the integration is our job that week, not a ticket in your backlog that competes with actual product work.
Security as a discipline, not a feature. AES-256 encryption (a widely used encryption standard), least-privilege API scopes, GDPR compliance (the EU's General Data Protection Regulation), and a choice of storage regions, including Frankfurt for teams with German data residency requirements. No hardcoded tokens in a script someone pasted from a chat window.
A restore that's been through real disasters. Our restore paths cover the scenarios that actually happen: single-record recovery, full-space recovery after a malicious deletion, point-in-time recovery (restoring data exactly as it was on a chosen date) after a bad sync or an agent gone wrong. More importantly, they've been exercised by a wide customer base across thousands of real incidents. Your DIY restore gets its first production test during your emergency.
The cost breakdown: $40 a month vs building it yourself
Assume a realistic DIY scenario: one technically capable team member, a vibe coding platform subscription, and a genuine intent to keep the thing alive.
Price out the person's time at even a modest internal rate and the DIY option costs more in month one than ProBackup costs in year one. And that's before valuing the thing you actually bought insurance for: the recovery working.
What good looks like
If you take one section from this post, take this one.
- Vibe code freely for tools where failure is cheap: internal dashboards, prototypes, automations, your own note-taking app.
- For anything that protects business-critical data, buy from a vendor whose entire business depends on the restore working, or commit to building with real engineering rigour: code review, dependency scanning, secret management, and scheduled restore drills.
- Whatever you choose, test a restore this quarter. Not an export. A restore.
- Audit which API tokens your homegrown scripts hold today, and what happens to them when their author leaves.
- Date your assumptions. An integration that worked "as of March" is not an integration that works.
Conclusion
The tension we opened with is real: vibe coding platforms are excellent, and getting better monthly, while the case against using them for backup keeps getting stronger. Both things are true because they're about different questions. Lovable answers "can I build this?" with an increasingly confident yes. A backup tool answers "will this work on the worst day of my company's year?", and that question is answered by maintenance, security discipline, and restores tested across thousands of real incidents, none of which fit in a prompt.
Build your next internal tool with AI. We probably will too. Just don't let the tool that guards everything else be the one nobody is maintaining. [Start your free trial] or [see which plan fits your team].
This post is written for IT admins, ops leads, and founders who are responsible for their organisation's data in SaaS tools, and who have at least once been tempted to just build it themselves.
