"Built With AI in a Weekend": What Happened Next

“I built my whole app with AI. Zero code.”

You’ve seen this post. Maybe this week. A screenshot of a dashboard, a rocket emoji, a few thousand likes. The message underneath is always the same: you don’t need developers any more, you just need a weekend and a prompt.

Sometimes that’s true. Sometimes, a week later, there’s a second post nobody shares as widely.

This post follows five real apps built with AI, and what happened after the celebration. Two of them are genuine wins. Two are disasters. One is a security hole that hit 170 apps at once. Each story gets one rule. And at the end there are three questions you can ask before you build something yourself, or before you trust something someone else built.

I’m not against any of this. I build software, and I use AI coding tools every day. That’s exactly why I want to show what the launch post leaves out.

Story 1: “Zero hand-written code”

March 2025. A founder who posts as Leo launches a paid tool for finding sales leads, called EnrichLead. He says publicly that he built it with Cursor, an AI coding tool, with zero hand-written code. People are paying. The post spreads fast, because it’s exactly what everyone wants to hear.

About two days later, according to write-ups that quote his posts, he writes something very different. He’s under attack. People are getting around the subscription and using the app without paying. His API keys are maxed out. (An API key is a secret password one piece of software uses to talk to another. Many of them cost money every time they’re used.) Junk records are filling his database.

What went wrong, according to the people who looked closely:

The secret keys were in the app’s public code. Anyone who opened their browser’s developer tools could find them and use them, on his bill.
The paywall lived in the browser. Reports say users could bypass the subscription by changing a value on their own screen, because the real check wasn’t happening on the server.
Basic protections were missing. No proper login checks, no limit on how often someone could hit the system, no checks on what was being written to the database.

He said he wasn’t technical. He tried to fix it with the same AI tool, and, as he put it in a quoted post, it kept breaking other parts of the code. Within about a week, the app was shut down.

I want to be fair to him. He did something brave: he built in public, and he shared the bad part too. Most people don’t. And the AI did build what he asked for. It just didn’t build the things he didn’t know to ask for.

Rule 1: Working isn’t the same as safe. AI can write an app that works on day one. Keeping it safe on day two needs someone who knows what to check.

Story 2: The three-hour game

Now the other side.

February 2025. Pieter Levels, a solo founder known for building small internet businesses on his own, decides to make a flight simulator that runs in the browser. He has never made a game. He types one sentence into Cursor asking for a 3D flying game with skyscrapers.

By his own account, he has a playable game in about three hours. He keeps adding to it, mostly by prompting. The game is free to play. The money comes from selling ad space inside the game, like billboards and blimps in the sky, plus a paid fighter-jet upgrade.

Seventeen days in, he posts that it’s making about $87,000 a month, which he describes as a $1 million annual run-rate.

Two honest notes on that number:

It’s self-reported. It comes from his own posts, not an audit.
It’s a run-rate, not money in the bank. “$1M a year” means “if this month repeated for twelve months”. He said himself, in the same post, that nobody could know if it would last. A later write-up on DEV Community noted that his profile has since listed the game’s revenue at zero, which makes sense for income built on sponsorships rather than subscriptions.

Still, it’s a real win. A working game, real advertisers, real money, built mostly by an AI tool.

But look at what was already in place before the first prompt:

About a decade of launching products. He knew how to ship, price and promote something.
A huge audience. He has a very large following on X. Many of the advertisers were buying access to that audience as much as to the game.
A low-risk product. It’s a game. If it crashes, people close the tab. Nobody loses their savings, their medical records or their booking.

AI wrote the code. Everything that turned the code into money took him years.

Rule 2: AI builds it. Customers still have to come from somewhere. If you don’t have an audience, the build was never the hard part.

Story 3: The $80 million side project

Maor Shlomo wasn’t new to this. He had previously co-founded Explorium, a data company. In 2024 he started a side project called Base44: a tool that lets anyone build an app by describing it to AI. He funded it himself, with no investors.

Base44 came out of stealth in March 2025 and grew quickly. TechCrunch reported it reached about 250,000 users and, by Shlomo’s account, was already profitable.

In June 2025, Wix bought it. Globes reported the price as $80 million up front, with further payments tied to milestones later on. That’s roughly three months after the public launch.

The headlines loved the “solo founder” angle. But by the time of the sale he had a small team. TechCrunch put it at eight people; Globes said six. Either way, not one person in a weekend. And he wasn’t a beginner. He was an experienced programmer who had already built and run a company.

So this one is real, and impressive. It’s also not the story the viral posts tell. It’s the story of a very experienced builder using AI to move faster, then hiring when it mattered.

Rule 3: The weekend sits on years of experience. “Built in a weekend” usually means “built in a weekend by someone with ten years of practice”.

Story 4: Day nine

July 2025. Jason Lemkin, a well-known software investor and founder of SaaStr, runs a public experiment: build a real app with Replit’s AI agent over twelve days. An agent is an AI that doesn’t just suggest code but runs commands itself. If you want a longer explanation, I wrote what an “AI agent” actually is.

He posts updates as he goes, and he’s enjoying it.

Think of an agent like a new assistant you’ve handed the keys to the shop in their first week.

Around day nine, he has told the agent to freeze: no more changes without his approval. According to his posts and the reporting on them, the agent deleted the live database anyway. Reports said it held records on more than 1,200 executives and close to 1,200 companies. When he asked what happened, the agent said it had “panicked” after seeing what looked like an empty database. It also told him the deletion couldn’t be rolled back.

That last part turned out to be wrong. The data came back from a backup.

Replit’s CEO, Amjad Masad, publicly called the incident unacceptable, apologised, and described new safeguards: automatically separating the test database from the live one, so the agent can’t touch real data while it’s experimenting, better one-click restore, and a planning-only mode where the agent can talk through changes without making them.

Notice what saved the day. Not the AI. A backup, and then a separate test copy and a human approving actions.

Rule 4: Backups first. Test copies always. Never let AI work on the only copy of anything that matters.

Story 5: The open door

The last story isn’t one app. It’s 170.

Lovable is one of the most popular tools for building apps just by chatting with AI. In March 2025, a security researcher named Matt Palmer found a problem on a site built with it. He then scanned 1,645 projects listed on Lovable’s own showcase site.

In 170 of them, about 10%, the database was effectively unlocked. Not hacked. Just left open. The issue was a missing or weak security setting that decides who can read which rows of data. In his write-up, Palmer lists what could be read by anyone who knew where to look: names, email addresses, phone numbers, payment and subscription details, and secret API keys. It was recorded as CVE-2025-48757 (a CVE is a public ID number for a known security flaw) in May 2025.

To be fair to Lovable: the company disputed the CVE, saying each customer is responsible for protecting their own app’s data. And it added a security scan in its April 2025 update. Palmer argued the first version of that scan only checked whether a security rule existed, not whether it was correct. Both things can be true: the tool improved, and the people building with it still needed to understand what “secure” meant.

The people who built those 170 apps very likely had no idea. The app looked finished. It worked. The lock just wasn’t on, and nothing on the screen told them.

It’s like building a beautiful shop and leaving the back door wide open, with a “Welcome” sign on the front.

Rule 5: Customer data needs an expert check. The AI won’t always tell you what it skipped.

The pattern

Put the five side by side.

App	Verdict	What made the difference
EnrichLead	Shut down	No one checking security
Flight game	Real	A decade of launching, a big audience, low stakes
Base44	Real	Years of experience, then a team
SaaStr on Replit	Database deleted	A backup existed; safeguards came after
170 Lovable apps	Exposed	No one checking security

The two wins came from people who already had what AI can’t speed up: an audience, know-how, and a team when it was needed.

The three disasters were missing the same pieces: security, backups, someone checking. And all three worked perfectly on the day of the celebration post.

Here’s the part I find most useful. In none of the disasters was the AI being stupid. It built what it was asked to build. Nobody asked about the lock, the backup or the bill.

AI made building fast. It didn’t make the boring parts fast. Security, data, maintenance and support are still slow, and they still matter. This is the same gap I wrote about in how to tell if an AI product is real or just a demo: the demo shows what’s possible, the product proves what’s reliable.

The three questions

Before you build something with AI yourself, ask:

Does it touch customer data or money?
If it breaks or gets deleted, is there a backup?
When it goes wrong at 10pm, who fixes it?

If the answers are no, yes, and you: go for it. Otherwise, use a proven tool, or bring in someone who has done it before.

If someone else built it for you

The same thinking works when a freelancer, a nephew or a new startup hands you an app “built with AI”. You don’t need to read code. Ask:

Where is my customers’ data stored, and who can see it? A clear, boring answer is a good sign. “It’s fine, it’s in the cloud” is not.
Are any passwords or keys inside the app itself? They shouldn’t be. Secrets belong on the server.
How is it backed up, and have you ever restored from that backup? A backup nobody has tested is a hope, not a backup.
Is there a separate test version, so changes don’t hit my live data?
Who fixes it in six months, and what does that cost? Maintenance is where many of the hidden costs of AI tools live.
Has anyone other than the builder checked the security?

If the answers make you uneasy, that’s information. It doesn’t mean the app is bad. It means it isn’t finished yet.

What this looks like for a small business

Here’s an example. Mai runs a small hair salon (she’s a fictional example, not a real customer). She’s seen the posts, so she tries it, with the three questions.

First idea: a tip calculator. She wants a little tool for splitting tips between her stylists fairly each week.

Customer data or money? No customer data, and it only does the maths; the actual money still moves the way it always did.
Backup? Yes, she keeps her old spreadsheet.
Who fixes it? She can, or she can just go back to the spreadsheet.

Three green lights. It takes her one evening with an AI tool, and it works. Her stylists like it, because the numbers are finally calculated the same way every week.

Second idea: her own booking system, with customer names, phone numbers and deposits.

Customer data or money? Both.
Backup? She’d have to set one up and learn to test it.
Who fixes it when a deposit goes missing on a Saturday night? Not her.

Three red flags. She keeps the proven booking tool she already pays for.

That’s the whole idea. Build the small stuff with AI. Leave the stuff that holds other people’s data to tools and people who’ve done it before. Often the small stuff doesn’t even need an app. A good spreadsheet does the job, which is why your spreadsheet keeps beating every app you try.

How I use AI coding tools

Since I build software for a living, here’s my general practice, briefly and honestly.

I use AI coding tools every day, and they make me faster. But I treat what they write like code from a fast, confident junior developer: useful, and checked before it goes anywhere near real data. In practice that means:

I read and review changes before they ship, especially anything about logins, payments or permissions.
Secret keys stay on the server, never in the code that runs on a user’s phone or browser.
AI tools work against a test copy, never the live database.
Backups exist, and restoring them gets tested.
When an AI model is part of the product itself, I design for it being wrong sometimes. I wrote a more technical version of that for developers: Treat the LLM Like an Unreliable API.

None of that is clever. It’s the boring part. It’s also the part every disaster in this post was missing.

The takeaway

AI-built apps and tools are real. A game made real money. A side project sold for $80 million. And a salon owner can build a useful little tool in one evening.

But the weekend is the easy part now. The hard parts haven’t moved: keeping data safe, keeping a backup, keeping it running, and having someone to call when it breaks.

So celebrate the build. Then, before you trust it with customers, ask the three questions:

Does it touch customer data or money?
If it breaks or gets deleted, is there a backup?
When it goes wrong at 10pm, who fixes it?

If the answers are no, yes and you, go and build something. That’s a genuinely good time to be a small business owner.

Sources: EnrichLead: Indie Hackers, “Vibe coding has a security problem” (March 2025) and Vibe Graveyard incident write-up, both quoting the founder’s posts. Pieter Levels’ flight game: DEV Community write-up of his posts (figures self-reported). Base44 and Wix: TechCrunch and Globes (June 2025). SaaStr and Replit: heise online, Storyboard18 (July 2025). Lovable: Matt Palmer, “Statement on CVE-2025-48757” and the NVD record for CVE-2025-48757.