Why AI App Builders Get Your Requirements Wrong

Last year, Bolt published a blog post with a title they clearly felt was brave: "We're solving vibe coding's fatal flaw."

The flaw, by their own description: "Most vibe coding tools are fun to start with - you can spin up a slick frontend in minutes - but they fall apart the moment you try to scale. They run on fragile infrastructure that's prone to bugs, downtime, and data loss."

They weren't wrong about the symptom. But they described the wrong disease.

Infrastructure instability is what you see. It's the broken build, the app that crashes under real traffic, the Supabase integration that silently failed while your users got blank screens. That's real. But it's downstream of something that happened earlier - before the first line of code was written, before you even opened the tool. The actual problem is that you started building before you knew what you were actually making.

Every AI builder on the market - Lovable, Bolt, Cursor, Replit, all of them - has the same design at its core: you type, it builds. Immediately. Nothing in between. That's the pitch and also the flaw. Not because speed is bad, but because the things that matter most about a real software product - the structural decisions about data, access, automation, and error handling - are invisible to a prompt box. The tool can't ask what it doesn't know to ask. So it guesses. And then you spend the next three weeks correcting those guesses, one broken prompt at a time.

The Session You Recognise

Picture this. You run a trade show business. Every show, you walk out with 30 or 40 contacts on business cards, a dozen follow-ups in your head, and no real system for what happens to any of it. You know what you want: something that tracks contacts, shows you where each lead came from, automates follow-ups, and flags who's going cold.

You open an AI builder. Thirty seconds later, something appears. Looks right. You keep going.

Two sessions later, you realise you never said that pipeline stage and lead source are different fields. They're not the same thing. One describes where a deal is sitting in your process. The other describes how it got there. You go back and correct it. Then you realise you want to assign leads to specific reps, not just log them centrally. Back again. Then the booking link - it needs to live on the contact record, not just link to a rep's calendar. Back.

Six sessions in, you're not building. You're undoing.

The context window is filling up with every correction, every patch on top of a patch, every "this works, don't touch it." The model starts losing track of what it decided in session two. New code starts working around old decisions it can't fully see anymore. People who've been through this describe it in remarkably similar ways: "frustrating loops", "the AI seemed forgetful", "simple request broke something else entirely." One developer on a forum described debugging AI-generated authentication code as "wandering in a labyrinth with no map."

The credits keep burning either way.

36 out of every 100 prompts sent to AI builders are error prompts. Not new features. Not improvements. Just getting back to a working state.

One in three prompts is recovery, not progress. A separate study of vibe-coded projects found that over 80% of rework - the time spent fixing things that already got built - traces back to requirements that weren't defined before building started.

That number isn't new. It comes from traditional software development research. What's new is that nobody's applied it to AI builders yet. The tools got faster. The underlying cause of failure didn't change.

The Problem Is Never the AI

This is worth being clear about because the failure of a vibe-coded build almost always gets blamed on the model. The AI didn't understand. The AI hallucinated. The AI lost context.

Sometimes that's true. But most of the time, the model did exactly what you told it to do. The problem is that what you told it to do and what you actually needed were two different things - and nobody surfaced the gap before building started.

Here's what that gap actually looks like.

When you say "build a CRM," a dozen structural decisions get made in the background by the model, based on whatever seems most common or obvious. Who can access what? One user model or multiple roles with different permissions? That choice shapes every access control decision in the codebase. Get it wrong and you're not adding a feature when you need to fix it - you're rebuilding the permission layer from the ground up.

How does automation trigger? On a date, a status change, a manual button, an inbound message? A time-based trigger and a state-based trigger are architected completely differently. Switching between them after the fact is a rewrite, not a tweak.

Where does data live? Shared across the whole business, or isolated per customer, per account, per region? This is the difference between a multi-tenant system and a single-tenant one. Most founders don't know the difference by name, but they feel it immediately when the system works wrong - either everyone can see everyone else's data, or building the next feature turns out to require a complete restructuring of the database.

What happens at the edges? When a payment fails halfway through processing. When a user tries to access a record they're not supposed to see. When someone cancels a booking that's already been confirmed in the calendar. These aren't edge cases. They're the parts that break loudly, in front of real users, and require real handling.

None of these are technical questions. Every founder can answer them. They're product questions, business questions. But they only get answered right if someone asks them before building starts.

The conventional software industry learned this the expensive way. Research from the Standish Group has tracked software project outcomes for decades. Only about 30% of software projects are truly successful. Projects where requirements were clearly documented before development started were 97% more likely to succeed. The number one reported cause of project failure, at 39% of all failed projects, is poor requirements management.

AI builders didn't fix this. They just made it faster to discover.

What the SalesCRM Build Actually Took

When a jewelry trade business came to Creatr, they knew they needed a CRM. Everything else was a conversation.

Not a long one. A few hours. But one that covered everything a blank prompt box would have guessed wrong.

Pipeline stage and contact source were completely different concerns. One describes where a deal is in the process. The other describes how the contact got there in the first place - trade show, referral, cold outreach, existing relationship. Their sales director had been trying to answer one question for two years: which shows actually generate deals that close? With those two fields merged into one, that question was unanswerable. With them separated, it's a five-second filter.

The booking link had to be on the contact record, not the rep's calendar. They'd tried it the other way. Clients would book with one rep and follow up with another and nobody had the conversation history. It created a week of confusion every single time.

Follow-ups needed to go out at 48 hours, 7 days, and 30 days - not because some article said those were good intervals, but because they'd tracked their own close rates and those were the windows where deals either moved or died.

And WhatsApp, not email. Their clients weren't checking email. Email follow-ups were getting around 8% open rates. WhatsApp was hitting 70%. Email still exists in the system - for records, for formal communication - but it's not the thing that actually moves anything.

None of this is unusual. Any sales business could tell you equivalent things about how they work. The point isn't that their requirements were exotic. It's that they were specific, and specificity is exactly what a prompt box can't capture on its own.

The requirements conversation took a few hours. The build shipped in days. Not because there was some shortcut, but because the system knew what it was building from the start - it wasn't discovering requirements by watching what broke.

Why Every Fast Tool Makes the Same Trade-Off

It's worth being fair to Lovable and Bolt here, because they're not wrong about what they built. They're just optimizing for something different than what most founders think they're buying.

The core product promise of every instant AI builder is: type something, see something, right now. That's genuinely valuable. For a landing page, a portfolio, a proof of concept, a demo - it's exactly the right tool. The requirements for those things are simple enough to discover through iteration. You prompt, you see, you adjust. The gap between what you described and what you need is small.

The problem is that most founders aren't building landing pages. They're building CRMs, booking platforms, client portals, internal tools with multiple user roles and complex automation logic. For those, the gap between what you described and what you actually need is not small. It's structural. And you can't close it through iteration after the fact - you close it through a conversation before.

There's a real difference between fast feedback - seeing output in thirty seconds - and fast delivery - having something that works the way your business actually runs. Every instant AI builder optimizes for the first one. Nothing wrong with that choice. But it means you're doing the requirements work either way. Either you do it upfront, in a conversation, where it costs a few hours. Or you do it retrospectively, one broken session at a time, where it costs weeks and a credit bill that some founders describe as a trap.

The ones who push past 50 sessions have usually rebuilt the same foundation two or three times. Not because they're doing something wrong. Because the tool was never designed to surface what it needed to know before it started.

What a Requirements-First Build Actually Looks Like

Before any code, you have a structured conversation - not with a blank prompt box, but with a process that knows what to ask based on what you're describing.

For a CRM: who are the user roles, what can each role do, what does the pipeline look like, what triggers automated actions, what integrations already exist in the business, what does a working end-of-week-one look like - specifically, not in general.

For a booking system: who can book, who manages availability, what's the scheduling logic, how does payment work, what happens on cancellation, does the client need their own portal.

These are product questions, not technical ones. Every founder already knows the answers. The value of asking them before building isn't that the answers are hard to find - it's that the answers need to be found before the architecture gets set.

Once they're answered, the build has a precise target. Not "build a CRM" but "build this specific CRM with these roles, this pipeline structure, these automation rules, these integrations." The output on day one is closer to what you'd have gotten after three weeks of iterative corrections - because the thinking happened before the building, not during it.

You still iterate. You still change things. But you're changing things to make them better, not to undo things that got built wrong because nobody asked.

Before You Open Any Builder

If you're about to start a build, one hour on these questions will do more than three weeks of iteration after:

Who actually uses this - is it one person, a team, or multiple user types who need to see different things? What are the three to five core actions the system has to handle, precisely? What data needs to be stored and how does each piece relate to another? What happens automatically, and what requires a deliberate human action? What does working look like at the end of week one - not in theory, but specifically?

You don't need a spec document. You don't need a technical co-founder. You need honest answers to those questions before the first session, not halfway through the sixth.

If you want a process that asks those questions properly - that runs the requirements conversation, surfaces the decisions that matter for what you're specifically building, and then ships a production-ready system from the result - that's exactly what DeepBuild was designed to do.