Guides / How to build

How to Build an App With Vibe Coding: From Idea to Published App

How to build an app with vibe coding, step by step: a one-page spec, the first prompt, data and login, testing, security, publishing and first users.

Mythex Team · 2026-11-01 · 7 min read

To build an app with vibe coding, write a one-page description of the first version, give it to an AI app builder as your first prompt, then grow the app in small tested steps: data, login, the main workflow, polish, a security pass, and finally publish. This guide follows one example project, a class booking app for a small yoga studio, through every stage, with the prompts used at each step.

If you've never built anything this way, our vibe coding tutorial for beginners starts smaller. For a broader overview that isn't tied to vibe coding, see how to build an app with AI.

The project

Imagine a yoga studio owner, Sara, who runs eight classes a week. Bookings come by WhatsApp; she keeps a paper list per class and often overbooks. She wants:

• Students to see the week's timetable and book a spot.
• Each class to have a capacity.
• A list per class she can check at the door.
• Students to cancel up to two hours before.

That's the whole first version. No payments, no memberships, no app store. Those come later, or never.

Step 1: Write a one-page spec

Before opening any tool, write down the first version in plain words. Ten minutes here saves hours of back-and-forth. A useful shape:

• Who uses it: students (book and cancel), Sara (manage classes, see lists).
• Screens: timetable, class detail, my bookings, admin classes, admin class list.
• Data: classes (name, teacher, start time, length, capacity), bookings (student, class, status), students (name, email, phone).
• Rules: no booking a full class; one booking per student per class; cancel up to two hours before; only Sara sees the admin pages.
• Not in v1: payments, class packs, waitlists, reminders.

The "not in v1" list matters most. It's what keeps the build finishable. Our guide to writing a product requirements doc with AI goes further if you want a fuller spec.

Step 2: Pick a tool that handles the whole loop

For an app with a database, logins and a public URL, use an AI app builder that runs the code, attaches a database and publishes, rather than a chat assistant that hands you files. Our comparison of vibe coding tools lists the options. We'll use Mythex here because it covers each step in one place: chat, live preview, a real database and file storage, and one-click publishing.

Step 3: The first prompt

Turn the spec into one paragraph. Don't paste the whole document at once with every detail; give the core and add the rest in steps.

Build a class booking app for my yoga studio. Students sign up with name, email and phone, see this week's timetable, and book a spot in a class. Each class has a name, teacher, start time, length and capacity; a full class shows "Full" and can't be booked. Students see their bookings and can cancel up to two hours before the class. I'm the admin: I can add and edit classes and see the list of who's booked for each one. Calm, simple design that works well on phones.

If you're unsure the tool understood, ask for a plan first. In Mythex, Plan mode lays out the screens and data before writing code, and you approve it.

Step 4: Get the core loop working

The core loop is the one thing the app exists for: a student books a class, and Sara sees it. Test only that:

1. Sign up as a student, book a class.
2. Open the admin view. Is the booking there?
3. Book the same class again. It should refuse.
4. Set a class capacity to 2, book it from two student accounts, try a third.

Two problems typically show up at this point. The timetable shows times in the server's time zone, not the studio's. And the "Full" check only happens in the page, so a fast double-click creates two bookings.

Show all class times in the studio's time zone, [Asia/Dubai], whatever the visitor's device is set to.

Check capacity and duplicate bookings on the server when a booking is created, not just in the page. If two requests arrive together for the last spot, only one should succeed.

Fix the core loop before adding anything. Everything else depends on it.

Step 5: Add the remaining rules, one per message

Now go through the spec's rules one at a time:

Students can cancel a booking up to two hours before the class starts. After that, hide the cancel button and refuse the cancellation on the server with a clear message.

Only my account can open the admin pages. Make sure this is checked on the server for every admin action, not only by hiding the menu.

After each one, test it, and move on only when it works. If a change breaks something, roll back to the last good checkpoint and try a clearer request instead of piling fixes on top.

Step 6: Polish what real users will notice

Real users notice small things. A short list for Sara's app:

• Empty states: "No classes this week yet" instead of a blank page.
• Confirmation: "You're booked for Vinyasa, Tuesday 18:00" after booking.
• Phone layout: big buttons, the timetable readable on a 375px screen.
• Spots left: "3 spots left" on each class, so students book sooner.

On each class card show spots left, e.g. "3 of 12 left". After booking, show a confirmation with the class name, day and time and a button to my bookings.

Step 7: Test like a stranger

Before anyone else uses it, spend half an hour trying to break it:

You can also ask the AI to run through edge cases:

List ten things a real student could do that might break booking or cancelling, test each one and fix what fails. Tell me what you changed.

Step 8: A security pass

This app stores names, emails and phone numbers, so a short security pass is worth it. The main questions:

• Can one student see another's bookings or contact details?
• Are any keys or passwords in code that runs in the browser?
• Is the sign-up form protected against bots?
• Is there a backup of the data?

Our page on whether vibe coding is safe explains each check and gives prompts for them, and the security checklist for AI-built apps is the long version.

Step 9: Publish

When the core loop, the rules and the checks pass, publish. On Mythex it's one click, and the app gets a public URL with its database and hosting already in place. On Pro you can connect your own domain, like book.sarasyoga.com; see how to connect a custom domain.

Before you send the link out, check the published version once more. Book a class from your phone. Production and preview should behave the same, but confirm it.

Step 10: First users and the next version

Give the link to five regular students first, not all of them. Ask them to book their next class through it and tell you what was confusing. Then fix the top three things they mention.

After a few weeks of real use, a v2 list for an app like this usually writes itself: a waitlist for full classes, email reminders the evening before, and class packs paid online. Each one gets the same treatment: spec it in a few lines, prompt it, test it, publish. For adding payments, see how to add payments to your app. For getting the word out, how to launch an app and get first users.

Turning it into a phone app

Many studios want an icon on their students' phones. On Mythex Pro, the published app can become an Android app (a file you can upload to Google Play) and an iPhone app sent to TestFlight with your own App Store Connect key, without a Mac. The phone app opens the published web app, so every time you publish an update, the phone app has it too.

What to take from this

The build itself was the short part. What made the app usable was the spec's "not in v1" list, testing the core loop before anything else, server-side rules for capacity and access, and five real users before fifty. That's what vibe coding looks like when the app has to work for other people.

Ready to try your own? Write your one-page spec, then paste the first paragraph into the AI app builder. If you'd like to see more app types and the prompts behind them, read our vibe coding examples.