Skip to content

// 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.

Show the checklist

$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
Cena~$46,000
Jmail — viral site and a $46,000 bill

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
Cena$82,314 in 48h
Stolen Google API key and an $82,000 bill

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
Cena€54,000 in 13h
Firebase and €54,000 in 13 hours

// 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
Cena€3,167 overnight
Public demo and an overnight bill of €3,167

// sources

clicking takes you off this page

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
Public project in Lovable — code and chat accessible to everyone

// 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
AI agent deleting the production database and backups

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
Change freeze ignored — tables deleted on production

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
AI tool and 13 hours of downtime at AWS

// 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.

[01]

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.

[02]

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.

[03]

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.

[04]

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.

or write directly: kontakt@rel8.pl

Leave a contact