I built an app in a weekend with a small idea. Just me, a chat window, and a tool that wrote almost all the code while I typed out what I wanted in plain English. Login page, done. Payments, done. A dashboard that actually looked decent, done. I remember feeling like a genius. Ten people signed up in the first week, mostly friends and one friend who I think joined just to make me happy.
Then something wonderful and terrifying happened. It got to 100 users after i posted it on reddit and social media. Then, a few months later, past 1000. And that is exactly when I started noticing things I had never thought about while the app only had 10 people using it. This article is basically me writing down everything I wish someone had told me at the start, plus a lot of what is happening right now across the whole vibe coding world in 2026, because it turns out my small app was not special. The same problems are showing up everywhere, at every scale, from solo builders to companies worth hundreds of millions.
I am not writing this to scare you off using AI to build things. I still use it every day. But there is a gap between an app that works for a demo and an app that survives contact with real users, real traffic, and real attackers. That gap is where most of the pain lives.
The 10 users stage: everything feels fine, and that’s the problem
At 10 users, basically nothing breaks. Your database has maybe 200 rows. Your server handles a handful of requests an hour. If something crashes, you notice within minutes because, well, it’s your friends texting you “hey the app is down.”
This stage is dangerous exactly because it feels good. The AI generated your backend, your auth, your database rules, and it all just worked. You tested it, clicked around, everything loaded fast. What you probably did not do is open your database console and check who else can read from it. You did not check if your API routes actually verify that user A cannot see user B’s data. At 10 users, if that access control bug exists, the odds nobody notices are extremely high. Ten people just are not going to poke around your endpoints.
This is more or less what happened with Moltbook, a social app for AI agents that launched at the end of January 2026. The founder said openly that he did not write a single line of code himself. Within days of getting real attention, security researchers found the entire production database wide open, including something like 1.5 million authentication tokens and 35,000 email addresses. The cause was not some genius hacker. It was a database that the AI had scaffolded with permissive access during development, and nobody went back to lock it down before it went live. The tokens sat there because at 10 users, or 100, nobody was looking hard enough to find them.
The 100 users stage: the cracks start showing
Somewhere around 100 users is where I first got a support message that made me go “wait, that shouldn’t be possible.” A user saw a small slice of another user’s data in a dropdown menu. Not a huge leak, just a name that shouldn’t have shown up. I fixed it in an hour. But it made me actually go read through the database rules the AI had written months earlier, and tbh, I found three more things like that just sitting there.
This tracks with what security researchers keep finding across the industry. A widely cited figure from research this year puts it at somewhere between 40 and 62 percent of AI generated code containing at least one security flaw, depending on which study you look at. Georgetown’s CSET found cross site scripting issues in 86 percent of AI generated samples they tested across five different large language models, and this was from completely normal prompts, not anyone trying to trick the AI into writing bad code. That’s the part that gets me. Nobody was trying to break anything. The AI just writes code the way it was trained to, and a lot of that training data came from a time before certain security patterns were standard practice.
At 100 users you’ll also start feeling actual performance issues for the first time. Queries that were instant with 200 rows start taking a second or two with 20,000 rows. If your AI generated backend never added proper indexes to your database (and it often doesn’t, because indexes are invisible until you have enough data for them to matter), this is when you feel it. Pages start loading slow. Nothing crashes yet. It’s just, sluggish. Annoying but survivable.
This is also roughly the stage where cost starts becoming a real line item instead of a rounding error. Your AI coding tool subscription, your hosting bill, your database provider, all of it starts adding up in a way it didn’t when you had ten friends using the app for free.
The 1000+ users stage: this is where it actually gets serious
Past a thousand users, you are no longer a hobby project. You are, whether you meant to or not, running something that real people depend on and that real attackers can find. And this is where the vibe coding story gets genuinely worrying, because the data on this is not vague anymore, it’s specific and it’s growing month over month.
Georgia Tech runs something called the Vibe Security Radar, a project that tracks confirmed security vulnerabilities that trace directly back to AI generated code. In January 2026 they attributed six such vulnerabilities. In February, fifteen. By March, thirty five in a single month. The researchers running the project think the real number across the open source world is probably five to ten times higher than what gets officially confirmed. That’s not a small trend line, that’s a curve going almost straight up.
And it’s not just small apps. Lovable, a vibe coding platform valued at something like 6.6 billion dollars with 8 million users, went through three separate documented security incidents in a two month stretch this year. One of them, a broken object level authorization bug, stayed open for 48 days after the company closed the original bug bounty report without escalating it internally. Security researcher Matan Getz had earlier found that more than 170 applications built on the same platform had their databases completely exposed, readable and writable by literally anyone, no login required. The apps looked fine from the outside. They had been tested. They had users. They were not fine.
A security firm called Escape.tech scanned 5,600 vibe coded apps built on platforms like Lovable, Bolt.new, and Base44, all of them live in production, not test environments. They found 2,000 highly critical vulnerabilities. 400 exposed secrets, meaning actual API keys and access tokens sitting in code anyone could read. 175 instances of exposed personal data, including medical records and payment information. Read that again. That’s not a hypothetical worst case. That’s what was actually sitting on the internet when researchers went looking.
Here’s the thing that really gets me though. Research out of Stanford, from Dan Boneh’s group, found that developers using AI coding assistants actually wrote less secure code than developers without AI help, and here’s the kicker, they were also more likely to wrongly believe their code was secure. The AI creates this feeling that the job is done because the feature works. Working and being safe are two completely different things, and vibe coding blurs that line more than any other way of building software I’ve seen.
I’ll admit something. When I first read these numbers I felt a bit defensive, like surely my app is different, I reviewed it myself. Then I actually sat down and audited it properly, hired a friend who does security work part time, and he found four issues in about two hours that I would never have caught on my own. One of them was a classic, an admin route that had no proper check on who could access it. It had been sitting there since roughly the 100 user mark. Nobody had used it against me. But it was there.
Do you need to scale the same app, or start over?
This is the question I get asked most when people find out I went through this. And really, the answer depends on what actually broke.
If your problems are purely performance, meaning things load slow, database queries time out under load, your server falls over during traffic spikes, you usually do not need to throw away the app and start again. You need to add proper database indexes, maybe move to a bigger database plan, add caching for things that get requested a lot, and possibly split one giant server process into a few smaller ones that can each be scaled independently. This is real engineering work but it builds on top of what you have. Vibe coding tools are genuinely decent at helping you make these changes too, as long as a human is reviewing what gets generated and understands roughly why.
If your problems are architectural though, that’s different. Sometimes an AI generated app was built with everything crammed into one place because that was the fastest way to get a working demo. No separation between your public facing code and your internal logic. Database access rules that were never properly designed, just left at whatever the AI defaulted to. In cases like this, patching individual bugs is like putting tape on a boat with a hole in the hull. You fix one leak and water finds another way in. At some point, and I hit this point myself somewhere around 800 users, it becomes cheaper and safer to properly redesign the core parts even if you keep 80 percent of the UI and the parts that were working fine.
TBH my opinion, and this is just my opinion, is that most people jump too fast to “rebuild everything from scratch” when actually they just needed a proper security and performance review of what already exists. A full rewrite is expensive, it takes time you don’t have, and it often reintroduces the exact same category of mistakes if you’re still building the same way, just faster this time. Fix what’s broken first. Rebuild only the parts that are structurally rotten.
Beyond hacking: privacy, availability, and the cost problem nobody budgets for
Security gets all the headlines because breaches are dramatic, but there’s a quieter set of problems that hit you just as hard as you scale, and almost nobody talks about them until they’re already a mess.
Privacy is its own animal, separate from security. You can have a technically secure app that still handles user data in a way that would horrify a privacy lawyer. AI generated code tends to log everything by default, store more data than it needs, and rarely thinks about things like data retention or the right for a user to actually delete their account and have their data gone. If you’re in India and your app touches health, financial, or minor’s data, or if you get even one user from the EU, you’re suddenly dealing with rules the AI never considered when it wrote your signup flow.Nobody prompts “please also make sure this complies with data protection law” and even if you did, I’m not convinced the output would actually hold up.
Availability is the next one. At 10 users, if your app goes down for twenty minutes at 2am, nobody notices. At 1000 users spread across time zones, someone is always awake and using your app, and downtime starts costing you actual trust, sometimes actual money. Vibe coded apps often skip basic things like automatic backups, health checks, or a proper way to roll back a bad deploy, because none of that felt necessary when you were the only tester. I found this out the hard way when a database migration I approved without fully understanding it locked out every user for close to forty minutes on a weekday morning. Not a hack. Just a mistake, generated confidently, approved by me without really checking it, deployed straight to production.
And then there’s cost, which sneaks up on you in a way I genuinely did not expect. A few things stack up quietly:
Your AI coding tool subscription scales with how much you use it, and as your app grows you’ll be prompting more, not less, because there’s more to fix and more features to add. Your hosting and database costs grow roughly with your user count, sometimes faster if your queries are inefficient, which they often are if nobody optimized them. And this is the one that really surprised me, the cost of fixing security debt later is much higher than building it in early, because by the time you notice a problem at 1000 users, it’s usually tangled up with three other features that got built on top of it.
There’s research this year on Fortune 50 companies that found AI assisted developers commit code three to four times faster than developers working without AI help, but they introduce security findings at ten times the rate. Speed and debt grow together. Nobody warns you about that trade when you’re vibe coding your first login page over a weekend.
What to actually do before you get to this point
If I could go back and talk to myself at the 10 user mark, here’s what I’d say, and none of it requires you to stop using AI tools, because really they’re too useful to give up.
Treat every piece of AI generated code the same way you’d treat code copied from a stranger on the internet. Read it before you merge it. Not every line in detail, but at least understand what it’s touching, especially anything near authentication, payments, or user data. Run a basic static analysis tool over your codebase. There are free ones. It takes twenty minutes to set up and it catches a shocking number of obvious problems.
Never let secrets, API keys, database passwords, live inside your code. This one single habit would have prevented a huge chunk of the incidents I read about while researching this, including big ones at platforms with millions of dollars behind them. Use environment variables or a proper secrets manager from day one, even when day one is just you and ten friends.
Actually check your database access rules, not just once, but every time you add a feature that touches new data. Ask specifically: can user A see or edit something that belongs to user B. This single question would have caught most of the incidents I mentioned earlier in this article.
Set up basic monitoring before you need it. A simple alert that tells you when something crashes, when error rates spike, when a database query starts timing out. This costs almost nothing and it means you find out about a problem in minutes instead of finding out from an angry user three days later.
And maybe the most boring but important one. Once your app crosses a few hundred real users, especially if it touches payments or personal information, actually pay a security person, even a freelancer for a day, to look at it properly. It costs less than one bad breach, and it costs a lot less than your reputation after one.
None of this is exciting advice. It’s not a game changer or some secret trick nobody else knows. It’s basically just doing the boring, careful parts of software engineering that vibe coding lets you skip in the moment, but that catch up with you eventually, one way or another, usually right around the time your app starts actually mattering to people.
My app is still running, by the way. Past 2000 users now. It broke twice this year in ways that genuinely scared me, and both times it was something I could have caught earlier if I’d taken this stuff seriously back when it only had ten users and felt completely harmless.