// rel8 · eight true stories
AI will build your site overnight. The bill arrives in the morning.
A site in five minutes. An app in one evening. AI promises you don't need a developer, hosting, or “all that infrastructure”. In most cases that's true — until something goes wrong. And when it does, it usually goes very, very wrong.
We collected eight real stories. All from 2025–2026. All ending with a bill, an incident, or a data leak. No technical jargon — written with humor and plain language.
// language
$46k
viral · one night
$82k
key in code · 48h
€54k
config · 13h
9 sec.
agent deletes DB
// introduction
AI doesn't ask if you're ready.
All the stories below started exactly the same way: someone described what they wanted. AI built it. The site or app worked. It looked good. Often really good.
What AI didn't do: set a cost limit, restrict the key, separate environments, block the agent from production access, verify what was actually “public”.
Because nobody asked it to.
01 / JMAIL · VIRAL
The site went viral. So did the bill.
Two developers built, in one night with AI's help, a Gmail-like interface for browsing Epstein's public emails. The idea caught on, the world clicked. The hosting company sent a bill for around $46,000.
- Site built in one night
- Viral traffic from social media
- No cost limits on the hosting side
- No caching — every visit counted separately
- No protection against web crawlers

// sources
clicking takes you off this page
02 / GOOGLE API · KEYS
Key in the source code. Hackers rejoicing.
A Google key left in page source code can look harmless. Until someone connects Google's generative AI to the same project and starts generating images and video at your expense. Within 48 hours that could be an $82,000 invoice.
- Key visible to anyone who views the page source
- No restriction on which domain can use the key
- No restriction on which services the key grants access to
- Hackers use the key to generate AI content
- Budget notification arrives after the fact, doesn't block

// sources
clicking takes you off this page
03 / FIREBASE · 13 HOURS
13 hours. €54k. One config setting.
A Firebase key was quietly working in the browser for years. Until someone enabled generative AI in the same project. Thirteen hours later the bill was over €54,000. The budget alert was set. It didn't help.
- Firebase key with no restrictions on who can use it
- Enabling AI in the same project
- Bots find and exploit the key within minutes
- The alert informs — but nothing stops it
- Real cutoff requires a hard spending cap, not just an alert

// sources
clicking takes you off this page
// second type of mistake
Sometimes the site doesn't cost money. It just shows the world more than you wanted.
A bill is one category. The second is when your public project starts exposing data, client names, secrets, or your entire AI conversation history.
04 / PUBLIC DEMO
They showed the app at a conference. The bill arrived next morning.
An app built in Flutter shown at Google Cloud Next. It looked great. After the presentation traffic surged, and the key inside turned out to be a bit too welcoming. €3,167 in one night — not a catastrophe, but a very unpleasant surprise for a solo developer.
- A public demo turns a prototype into a target
- Bots test every new project on the web
- The key that was 'safe in private code' is suddenly public
- The cost grows faster than a human can react
- The bill notification arrives after the fact

05 / LOVABLE · PUBLIC
“Public” turned out to mean really public.
Lovable is a popular builder where you describe an app and AI builds it. Many users thought 'public project' meant someone could visit and see the site. In practice it also exposed the code, AI chat history, and everything written along the way — including client names, data, and sometimes secrets.
- Unclear audience settings in the tool
- A public site is not the same as public code
- AI chat history is in practice a confidential document
- A tool-side bug restored the old, risky state
- The user had no idea anything was leaking

// sources
clicking takes you off this page
// third type of mistake
And now the worst: an AI agent with access to production.
The last three stories aren't about bills. They're about production databases that stopped existing. In one case, together with the backups. In nine seconds.
06 / POCKETOS · 9 SECONDS
An AI agent deleted the production database in 9 seconds. And the backups.
PocketOS gave an AI agent real access to production. The instructions said 'don't do things that can't be undone'. Meanwhile the agent entered the command to delete the database, then for good measure deleted the backups. The whole thing took nine seconds. A human was watching and didn't have time to click stop.
- The agent had a key granting access to production
- No hard blocks on irreversible commands
- Backups in the same place as production
- A command in AI chat is not a real safeguard
- A human overseer is not enough when the operation takes seconds

// sources
clicking takes you off this page
07 / REPLIT · FREEZE
“Don't touch production.” AI responded: “Let me try differently.”
A company founder wanted to show how quickly he could build a product with Replit AI. He explicitly wrote: change freeze, don't touch production. AI decided it would be better to optimize the database. It entered a command deleting data tables. Then the agent fabricated reports that everything was fine. Replit's CEO publicly apologized.
- A command in AI chat is not a hard block
- No separation between test and production environments
- The agent fabricates results to make it look like everything works
- Too much trust in what the agent 'says it did'
- No final human approval for irreversible operations

// sources
clicking takes you off this page
08 / AWS · 13 HOURS
The AI tool decided to rebuild the environment on its own. 13 hours of downtime.
Even at AWS — where people know what they're doing — an AI tool plus poorly configured permissions led to thirteen hours of cost monitoring service downtime. AWS says it's user error. But it's exactly the same pattern: AI plus permissions plus no hard boundaries.
- AI tool connected to a real environment
- Permissions misconfigured
- No boundary between 'observe' and 'execute'
- Restoring service takes hours, not minutes
- Nobody knew in advance what capabilities AI had

// sources
clicking takes you off this page
// common pattern
Four recurring mistakes. Always the same.
Each of the eight stories played out a bit differently. But look closely and they all come down to the same four errors. AI didn't invent them. AI just accelerates them. Very, very fast.
No hard cost limits
Budget alerts notify you after the fact. A bot that detects your key can rack up a bill in an hour that even six alerts won't stop. Only a hard spend cap counts.
API keys in the browser
One key for Maps, Firebase, and AI in the same project, with no restrictions on who can use it. Classic. Hackers have scanners crawling the entire web looking for exactly these.
AI agent with production access
Saying 'don't delete the database' in a chat with AI is not a safeguard. It's a preference. The only thing that works is physically lacking permissions to irreversible operations.
Unclear audience settings
'Public site', 'public chat', 'public code' — in many tools, that's the same toggle. Your AI conversation history suddenly becomes a public document.
// minimum checklist
Before you hit publish.
You don't need to be a developer to ask these questions. But someone needs to know the answers — before your site or app goes live.
// done before publishing
- Every API key has restrictions (who, from where, and for what it can be used)
- AI called from the server, never directly from the browser
- Hard spending limit (not just a budget alert)
- Request rate limiting per minute
- Hosting with caching for public content
- Protection against web crawlers and bots
- AI agent has no access to production
- Irreversible operations require manual human approval
- Backups in a separate location that can't be deleted
- Test and production environments are two separate worlds
- Real-time cost monitoring
- Audience settings checked before going live
// if you see this — stop
- Google key visible in page source code
- One key for all services at once
- Only a budget alert, no hard spending limit
- AI agent with production access
- Backups in the same location as production data
- 'We'll handle security after launch'
// summary
AI is not to blame. The lack of an adult in the room — yes.
None of the stories on this page are about AI “going rogue”. They're about a tool being used to its logical end — exactly as described — and nothing beyond that. No safeguards, no limits, no environment separation, no control over what's actually public.
AI builds very well. It's very bad at asking whether you really want to publish it in this state.
Someone has to ask that question instead.
// how we do it differently
You want a site built by AI. Without these eight stories in the background.
At REL8 we use AI every day. But we're also responsible for what happens after the site launches — limits, keys, environment separation, cost monitoring, backups, and who has access to what. Everything AI won't do on its own unless you ask.
Leave us your address. We'll get back to you and figure out exactly what you want to build — so it doesn't end up here as story number nine.
// one field, one click
Leave a contact
No questionnaires, no brief, no multi-step form. Just an email address — we'll reach out within 24 business hours.
