Most of the vibe coding disasters I get called in to clean up did not start with bad code. They started with a bad idea of what to build. The founder opened Cursor or Lovable, typed something like "build me a marketplace for local tutors," and watched the AI produce thousands of lines in minutes. It looked incredible. Then, a few weeks in, they realized the thing it built was not the thing they actually needed.

I see this almost every week. The prompt was vague, so the AI filled in the blanks with its own assumptions, and now there is an expensive pile of the wrong features standing where the right app should be. The problem was never the AI's coding ability. The problem was that nobody told it clearly what to make.

So let me show you how to spec an app before vibe coding, in plain English, without becoming a developer. If you get this one thing right, the AI stops guessing and starts building the app you actually pictured in your head.

What a "spec" actually is (and why yours is probably missing)

A spec is short for specification. Strip away the jargon and it is just a written description of what your app should do, clear enough that someone who is not you could build it without asking a hundred questions.

That is exactly the situation you are in with an AI builder. The AI is not you. It does not know your business, your users, or what you meant by "make it simple." It only knows the words you typed. When those words are vague, it does what any contractor with no blueprint does: it makes something up and keeps moving.

Here is the part that trips up non-technical founders. A vague prompt still produces a real, working, impressive-looking app. So it feels like it worked. You do not find out it built the wrong thing until you try to use it, sell it, or add the next feature and everything fights you.

A working app built from a vague prompt is not a win. It is an expensive misunderstanding that happens to compile.

Why vibe coding fails without a spec

The reason comes down to how these tools work. An AI builder is a prediction machine. You give it words, and it predicts the most likely code to satisfy those words based on everything it has seen. It is genuinely good at this. It is also completely willing to invent details you never gave it.

When you type "build a booking app," the AI has to answer dozens of questions to write any code at all. Who books whom? Do users need accounts? Is there payment? Can a booking be canceled? What happens when two people book the same slot? You did not answer any of that, so the AI silently picks answers for you. Usually the simplest ones. Usually the ones that look fine in a demo and fall apart in real life.

This is why "just keep prompting" feels like wading through mud after the first burst of magic. Every new prompt collides with an assumption the AI baked in earlier. You ask for a small change and it breaks three things you did not know were connected. I wrote more about that specific pain in why fixing one thing breaks another in AI-built apps, and a shaky foundation is almost always the root cause.

The compounding effect is real. Every feature you stack on top of an unclear foundation adds to what I call vibe coding debt: the invisible pile of shortcuts and wrong assumptions you eventually have to pay back, with interest.

What "building the wrong thing" looks like

You do not need to read code to recognize these symptoms. If any of these sound familiar, the issue is almost always a missing or fuzzy spec.

  • The app does something adjacent to what you wanted, but not it. You asked for a way for coaches to sell sessions, and you got a generic calendar with no payments and no coach profiles.
  • Core rules are wrong or missing. Anyone can see anyone's data. A user can book a slot that is already taken. There is no concept of "admin" versus "customer."
  • You keep discovering features you never asked for. The AI added a messaging system, a notifications panel, and a settings page you do not need, and now they all need maintaining.
  • Every conversation with the AI starts with "no, that is not what I meant." You spend more time correcting than building.
  • You cannot explain, in one sentence, who the app is for and what it lets them do. If you cannot, the AI definitely cannot.

None of this means you failed. It means you skipped the step that would have made the AI aim before it fired.

How to spec an app before vibe coding

Here is the good news. A useful spec for a first app is not a fifty-page document. It is one or two pages you can write in an afternoon. You do not need technical language. You need to be specific about the things the AI would otherwise guess.

Let me walk you through the parts that matter most.

Step 1: Write one sentence that says who and what

Before anything else, finish this sentence: "This app lets who do what so they can why."

For example: "This app lets independent tutors list their availability and get paid for sessions so they can stop chasing invoices." That single sentence rules out a hundred wrong turns. It tells the AI who the user is, what the core action is, and what success looks like.

If you cannot write this sentence cleanly, stop. Everything downstream depends on it.

Step 2: List the actual users and what each one can do

Most apps have more than one kind of user, and they are not allowed to do the same things. This is the single most common thing I see missing, and it is where security holes are born.

Write it out plainly:

  • Tutor: creates a profile, sets availability, sees their bookings, gets paid.
  • Student: searches tutors, books a slot, pays, leaves a review.
  • Admin (you): can see everything, remove bad actors, issue refunds.

This list is doing something important. It defines who is allowed to see and do what, which is the foundation of getting permissions right. When founders skip it, the AI tends to build an app where everyone can access everything, which is exactly how AI-built auth ends up broken.

Step 3: Describe the core flows step by step

Pick the two or three things your app absolutely must do and write them as numbered steps, the way a real person would experience them. Do not describe screens. Describe the journey.

Student books a session:
1. Student searches by subject and sees available tutors.
2. Student opens a tutor's profile and picks an open time slot.
3. Student pays for the session up front.
4. The slot is now marked taken so nobody else can book it.
5. Both people get a confirmation with the meeting link.
6. If the student cancels 24+ hours ahead, they get a refund.

Look at how much that clarifies. It tells the AI there is payment, there is a booking-conflict rule, there is a cancellation policy, there are confirmations. Every one of those is a decision the AI would otherwise make for you, usually wrong. Payment flows in particular are where I see the most costly guesses, and I broke those down in the payment integration mistakes vibe-coded SaaS apps make.

Step 4: Write down the rules and the edge cases

The happy path is easy. The money and the trust live in the exceptions. Spend ten minutes listing what should happen when things go sideways:

  • What if two people try to book the same slot at the same second?
  • What if a payment fails halfway through?
  • What if someone enters a wildly wrong value?
  • What can a logged-out visitor see, and what requires an account?

You will not catch every case, and that is fine. Writing even a handful forces the AI to handle reality instead of only the demo. This is also the raw material for testing later, which I cover in how to QA test an AI-built app.

Step 5: Say what is explicitly out of scope

This one feels backwards, but it is powerful. Write a short list titled "Not now." Messaging, mobile app, dark mode, social login, whatever you are tempted by. Naming what you are not building keeps the AI from wandering into it and keeps your first version small enough to actually finish.

A smaller, correct app beats a sprawling, wrong one every single time.

Step 6: Note the data you are storing

You do not need database expertise here. Just list the main "things" your app tracks and what you know about each one:

  • Tutor: name, subjects, hourly rate, availability, payout details.
  • Booking: which tutor, which student, time, price, status (booked, completed, canceled).
  • Review: which booking, rating, comment.

This small list quietly shapes a sane structure underneath your app. Getting it roughly right early saves you from painful rework later, which is a big theme in designing a database schema that can actually scale.

How to use the spec once you have it

Do not paste the whole document in and say "build this." Feed it in pieces. Give the AI the one-sentence summary and the user list first, and let it set up the foundation. Then hand it one core flow at a time and confirm each works before moving on.

Working in small, defined chunks does two things. It keeps the AI focused, and it lets you catch a wrong turn after one feature instead of after twenty. When the AI drifts, point it back at the spec: "The booking flow says the slot must lock after payment. It is not locking. Fix that." Now you are correcting against a written standard instead of a vague memory.

Keep the spec updated as you learn. It is a living document, not a monument. Every time you discover a rule you missed, add it. Your spec becomes the source of truth that both you and the AI keep coming back to.

Where a spec ends and a real review begins

A good spec dramatically raises your odds of getting the right app. It does not guarantee the AI implemented it correctly under the hood. The AI can build exactly the flow you described and still leave the data open to anyone, still make calls that quietly run up your bill, still skip the safety nets that keep it alive after launch.

That is the honest line. A spec makes sure you are building the right thing. It does not verify the thing was built safely. Checking that the permissions actually hold, the payments actually reconcile, and the app will not fall over when real users arrive is a different skill, and it is exactly the kind of work I get pulled into once a founder has something real. If you are already past launch and things feel shaky, figuring out who maintains an AI-built app is worth reading next.

You are the one who knows what to build

Here is what I want you to take away. The AI is a fast, tireless builder. It is not a mind reader, and it will never care about your business the way you do. The clarity has to come from you. When you show up with a simple, specific spec, the same tool that used to produce an expensive pile of wrong features starts producing the app you actually wanted.

So before your next prompt, spend the afternoon. Write the one sentence, list your users, map your core flows, name your edge cases, mark what is out of scope. It is the highest-leverage hour you will spend on the whole project.

If you have already vibe coded something and you are staring at it wondering whether it is the right app built the wrong way, or the wrong app entirely, I can help you sort that out. I review AI-built apps every week, tell you plainly what is solid and what is not, and either fix it or hand you a clear plan. If that would take the guesswork off your plate, let's talk about what your app actually needs.

Cover photo by Ivan S on Pexels.