It looks finished. It’s just slow and buggy, and nothing is quite right.
That’s how a founder usually describes a vibe-coded app. They can’t say why, because it’s intangible. It’s like a film with the sound a fraction out of sync. You can’t point at the problem, but you can’t ignore it either.
Vibe coding is amazing, by the way. Do it. Keep doing it. But here’s how I find out what you’ve really got.
Scroll first
Users don’t care about your code. They just want the app to work. But how your app feels is made of code, so I can’t ignore it.
The first thing I check is scroll performance. It’s the biggest clue I can get without opening the code. A smooth scroll usually means the app is well built, maintainable and native.
A bad one usually means everything is running on the main thread. Imagine 12 seats in a room, and everyone queues for the same one.
Then I scroll past the end of the list. If it doesn’t overscroll, or the movement feels off because the animation isn’t native, something has gone wrong somewhere.
Then I look for a dialog. If it isn’t a native one, whoever built it has told me how much care went into the rest of the app. Does it animate in and out? Does that animation use springs or easing? Can it handle several buttons? Does it dim the background, and does it feel like part of the app?
Then I do the things everyone does without thinking. I tap the edge of a text field. I type until the keyboard should push the field up. I swipe from the left edge to go back. I scroll down a list and back up, and watch if the pictures load again. I tap a button twice, quickly. Then I make the text bigger in Settings and open the app again. iOS gives you all of this for free. When an agent rebuilds it by hand, it usually forgets some of it.
Then I check the file size, and I open the app up. An IPA is only a zip file, so anyone can look inside. Some apps I’ve checked had full markdown files in there, with plans, prompts and lessons, shipped to every user. If nobody checked what went into the app, what else didn’t they check?
It’s not the AI
I’ve helped a lot of clients rescue or rewrite apps built by cheaper remote teams. Many of them put their best developers forward to win the work, then hand it to juniors who don’t know what they’re doing. You get what you pay for.
One client didn’t go with me, because another team promised two weeks against my eleven. Seven months later they came back. The app still wasn’t finished, it still wasn’t fast enough, and their seed funding was gone. I suggested a quick review, but my gut said it couldn’t be saved.
An agent is a lot like a junior. It’s a junior at everything, so it will help you with advanced work, in a junior way. It’s a strange thing to watch, and it’s the worst it will ever be.
And like a junior, it’s only as good as its guidance. Agents do amazingly well on benchmarks, because each one is a single task with clear rules. The first few prompts on a new app usually go well too. It’s the follow-up prompts that cause the trouble. When a vibe-coded app goes wrong, the problem was rarely the AI. It was the prompts and the guidance it was given.
An agent also mostly adds code. It rarely removes or rewrites any. A seasoned developer often removes more code than they write. So after months of tweaks and bug fixes, you have spaghetti code, with everything tangled together. Nothing is technically wrong, but you can’t lift out a screen or a feature to try something new. A change in one place doesn’t reach the others. And every fix starts a game of whack-a-mole.
None of this is special to AI. “AI slop” is no different from human slop. Bad craftsmanship is everywhere: look at any house built in the last 15 years.
Whether it hurts depends on how the founder thinks, not on the AI.
Give an agent barely any information and it has to make assumptions. Then you spend the rest of the project steering it away from them. Think it through up front, or build it step by step, and you’ll usually be fine. And if you can spot the signs, or get someone who can, you can skip a lot of the pain.
You got the important part right
I’ve spent my entire career telling people to distil their product down to one core thought and build that. You can get to the other 49 features later, along with the merchandise, the branding and the corporate retreats. Your core thought may be wrong, so find out first.
Vibe coders have cottoned on to something important. Build it fast and keep it small. Release it, then iterate or drop it.
Strangers change everything
Trying costs nothing. Your obligations start when strangers use your app, and the more strangers you have, the more you owe them.
Moving fast doesn’t change that, and it counts ten times over on the App Store.
You still have permissions, legal requirements and platform rules. You have data storage rules that differ from country to country. And you have the states nobody designs.
You still have users who don’t want to be tricked. That means no fake onboarding, no pressure selling, no deceptive advertising, and no rating prompt before they’ve used the app.
You also have their data to look after. It’s very easy to corrupt a database during a migration, or to not migrate at all, and ruin your app and your reputation with it.
There’s a reason app icons shake when you’re about to delete them. Once someone deletes your app, they rarely come back. It’s one and done.
Apple isn’t the enemy either. It has no rule against vibe coding, but it enforces the rules it has, so treat a rejection as a warning and fix the actual problem.
Keep it, fix it, sell it or scrap it
If it works, it works. If your app is bringing in users and revenue, and you can justify the next version, invest in it.
An app rarely loses money because of its code. If it’s crashing, fix the crash. Don’t rewrite it for that.
When code does need changing, I have a rule of thumb. If you’re editing more than 40% of it, rewriting is usually faster. The exception is code full of domain knowledge, and then you’re in for some fun. But a vibe-coded app rarely has much secret sauce.
If nobody is downloading it or reacting to the marketing, the idea or the marketing is bad. Usually it’s not a code problem. Scrap it.
If people are downloading it but it isn’t making money, and you can’t afford to fix it properly, sell it. You won’t get what you wanted, but it might take off with someone else, and you could keep a small share or become a partner.
If you’re keeping it, here’s how to fix it.