How to vibe code: a step-by-step guide for non-developers

Kiril Hristov
Kiril Hristov
Co-founder, Product, OpenKBS ·

To vibe code an app, you describe what you want to an AI in plain language, try what it builds, and keep asking for improvements until you're happy with it. That part takes minutes to learn. Getting an app your business can rely on takes a bit more method, and most of it happens before the first prompt and after the app seems to work.

One thing before the steps. At OpenKBS we don't think there's a best way to vibe code. People who build good apps work in very different ways, and the AI understands all of them: any language, typos, half-finished sentences, the way you'd explain something to a colleague over coffee. The models also get better at this every few months, so we don't think learning to "prompt" is worth much of your time. The part that matters is having a clear idea of what you want the app to achieve. Get that figured out and we're sure you'll make a great vibe coder. The steps below are for when you're struggling to get going or keep getting stuck. If you'd rather open a tool and type what you want, do that. It's the best vibe coding tutorial there is.

This guide walks through that method with one running example. A renovation company with six people takes quote requests by phone, email and WhatsApp, and a few slip through every month because nobody wrote them down. The owner wants a simple system: customers fill in a form on the website, the office sees every request in one list, and each request has a status from "new" to "won" or "lost." It's a realistic first project, and every step below applies to whatever you're building instead.

If you're not sure what vibe coding is yet, read what vibe coding is and where it came from first.

Step 1: Pick one small problem that annoys you every week

The best first project is boring. It replaces a spreadsheet, a paper form or a WhatsApp thread that already causes trouble, and you can describe it in two sentences. This one passes that test:

Customers request quotes through a form, and the office tracks each request until it's won or lost.

This one doesn't:

An app to run the whole company.

The second will drown you in decisions before you've learned how the tool behaves.

A small project also tells you quickly whether the result is any good, because you already know exactly how the old process fails. If the new tracker stops quotes from going missing, it worked. You don't need anyone else's opinion.

Step 2: Write a one-page brief before you open any tool

This is the step beginners skip, and it matters more than any prompt you'll write. Most of what looks like prompting skill is really just knowing what you want. Once that's on paper, the messages are easy. It also saves money, because every vibe coding tool charges for the messages you send while you figure out what you meant. Ten minutes in a text document saves twenty rounds of "no, not like that."

Answer four questions. Who uses it, what each of them does, what rules the app must enforce, and how you'll know it's done. For the renovation company it looks like this:

WHO
- Customers: fill in a quote request form on our website. No login.
- Office staff (3 people): log in, see all requests, update status, add notes.
- Owner: same as office staff, plus can delete requests and see a monthly summary.

WHAT
- Form fields: name, phone, email, address, type of job (bathroom, kitchen,
  flooring, other), short description, up to 5 photos.
- Office list: newest first, filter by status and job type.
- Statuses: new, visit booked, quote sent, won, lost.

RULES
- Phone and job type are required.
- Customers get a confirmation email within a minute of submitting.
- Office staff can't delete anything. Only the owner can.
- Customers never see other customers' requests.

DONE WHEN
- A test request from my phone shows up in the office list with its photos.
- The confirmation email arrives in a normal Gmail inbox, not spam.
- Logged in as office staff, I can't find a delete button.

People often ask us for a vibe coding prompt template. This document is the closest thing we'd recommend, because it's in your words, not ours. You'll paste parts of it into the chat over the next few steps, and you'll come back to it whenever the app drifts from what you wanted.

Step 3: Choose a tool and start on the free plan

For a project like this you want a tool that doesn't make you touch code and includes a database, logins and email, because the brief needs all three. Our guide to the best vibe coding tools covers eight options. OpenKBS, which we make, is built for exactly this kind of business app, so it's on the list too.

Whatever you choose, start free. You'll learn more about a tool in the first hour of building than from any review, and switching costs nothing while the app is small.

Step 4: Ask for the smallest useful version first

The temptation is to paste the whole brief and say "build this." Sometimes it works. More often you get something that does most things half right, and untangling it costs more than building it in pieces would have.

Start with the core and nothing else:

Build a quote request system for a renovation company.

  1. A public form with these fields: name, phone (required), email, address, job type (required: bathroom, kitchen, flooring, other), and a short description.
  2. A page for logged-in office staff that lists all requests, newest first, with a status for each: new, visit booked, quote sent, won, lost.

Leave out photos, emails and the summary for now. We'll add them next.

There's no clever wording in there. Whoever wrote it simply knew what they wanted: exact field names instead of "the usual stuff," and a clear note about what to leave out. The AI fills any gap with a guess, so the more you say what you actually mean, the fewer guesses you'll have to undo.

When it's built, add one feature per message: the photos, then the confirmation email, then the owner's delete permission, then the monthly summary. Check each one before asking for the next.

Step 5: Ask for changes the way you'd ask a person

You'll spend most of your time here, clicking through the app and asking for improvements. You don't need special phrasing. Write the way you talk, in whatever language you think in, typos and all. What makes the difference is detail.

"The form doesn't work" gives the AI nothing to go on. Compare it with this:

When I submit the form without a phone number, it saves anyway. Phone should be required: show "Please add a phone number" under the field and don't save the request.

That message says what you did, what happened and what should have happened. It's the same thing you'd tell a developer, and the AI responds to it the same way. If something looks wrong, a screenshot helps, and most tools let you attach one.

Two habits make this stage much smoother. Change one thing per message, so that when something breaks you know which change broke it. And when a version works, note it or save it (most tools keep a version history), so you always have a known-good point to return to.

Step 6: When you're stuck in a loop, stop after three tries

Every vibe coder hits the same wall eventually. You report a bug, the AI says it's fixed, it isn't, you report it again, and twenty minutes later the photos upload but the form no longer saves. Each round costs credits, and the app is getting worse.

Our rule is three attempts. If the same problem survives three fixes, stop. Go back to the last version that worked, then try one of these instead of repeating yourself:

  • Describe the problem from a different angle, for example by explaining what the user is trying to do instead of what the screen shows.
  • Split the feature smaller. "Let customers upload photos" can become "add a single photo field" first, and "allow up to five" once that works.
  • Ask the AI to explain what it thinks is happening before it changes anything. Its explanation often shows that it misunderstood the request in the first place.

This is also the moment to remember the billing. Most tools charge per message or per unit of AI effort, failed attempts included, so a stubborn loop is the most expensive thing you can do in vibe coding.

Step 7: Lock down who can see what, then try to break it

Your app works when you use it. Now check that it works when other people use it, including people who shouldn't be able to do certain things.

Go back to the rules in your brief and test each one as the person it's meant to stop. Log in as office staff and look for a way to delete a request. Open the form in a private browser window, submit a request, and check that nothing on the page shows anyone else's details. Then ask the AI directly:

List every page and action in this app, and who can use each one.

Compare its answer with your brief, line by line.

This matters more than it sounds. In 2025, a security researcher found 170 apps built on one popular vibe coding platform whose customer data could be read by anyone, and the apps looked perfectly fine on screen. We covered it in where vibe coding goes wrong. The fix is rarely hard. Somebody just has to check.

Then hand the app to two people who weren't involved and ask them to break it. One of the office staff will try things you never thought of within five minutes, like submitting a request with an emoji as the phone number.

Step 8: Go live on your own domain

A tool's preview link is fine for testing. For customers, the form should live on your own domain, for example quotes.yourcompany.com, so it looks like part of your business and doesn't break if you change plans. Most tools connect a domain you already own on their paid plans.

Check the email properly before you announce anything. Submit a real request with a Gmail address and an Outlook address and see whether the confirmation lands in the inbox or in spam. Emails sent from an unverified address often go straight to spam, and customers who don't get a confirmation tend to call, which is the problem you were trying to solve.

Then ask the question that separates a demo from software you can run a business on. If someone deletes every request at 4pm on a Friday, how do you get them back? You want a specific answer: backups that happen automatically, and a way to restore to a point in time. If the answer is "contact support," write that down and decide whether you can live with it. This is the area we focused on most when we built OpenKBS, where every project has a database you can restore to any moment, plus its own domain and email, so you can answer these questions before launch instead of after.

Step 9: Keep a list, and change one thing a week

Once people use the app, requests start coming in. The office wants a "visit date" field, and the owner wants to see which job types win most often. Keep a running list instead of building each request the moment it arrives, and make one or two changes a week. Test each one the way you tested the first version, because a new feature can quietly break an old rule.

Martin, an aircraft engineer who had never written code, built the 115,000-line JobAvion platform on OpenKBS this way, one requirement at a time over several months. A renovation company's quote tracker won't get that big, but it's built with the same loop of one clear request, one test and one fix at a time.

A few more vibe coding tips

These didn't fit neatly into a step, but each one has saved us real time.

  • Use the planning or chat mode if your tool has one. Several tools let you discuss a change before the AI touches anything, and it's cheaper to catch a misunderstanding in a conversation than in a broken page.
  • Ask for sample data early. "Add 20 realistic test requests across all statuses" shows you how the list, filters and summary behave long before real customers fill them.
  • Keep your names consistent. If the brief says "quote request," don't switch to "lead" or "enquiry" halfway through, or you may end up with two things that are meant to be one.
  • Never paste passwords, card numbers or API keys into the chat. When the app needs a key for another service, use the tool's settings for secrets.
  • Give exact numbers whenever you can. "Up to five photos, 10 MB each" leaves nothing to guess, and "a few photos" leaves everything.

None of this is required. Plenty of people skip every step above and do fine, and everyone ends up with their own way of working. If you've read this far and still haven't started, close the tab, open a tool, and describe the first thing that annoys you at work.

More in this series

Start building free · Talk to us about a custom build

Vibe codingHow to vibe codeVibe coding promptsNon-developersAI app builder