Guides / How to build

Vibe Coding Examples: 10 Real App Types, Prompts and What Went Wrong

Ten vibe coding examples: the kinds of apps people really build, the first prompt for each, what usually goes wrong and the follow-up prompt that fixes it.

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

The most common vibe coding examples are small, useful web apps: trackers, booking pages, internal tools, client portals, landing pages, quizzes, dashboards and simple AI tools. Below are ten of them. For each one you'll see who builds it, the first prompt, what usually goes wrong, and the follow-up prompt that fixes it.

These are composites of the projects people most often bring to AI app builders, not case studies of one person. The prompts are copyable. The failures are the ones that come up again and again, which is why they're the useful part. If vibe coding itself is new to you, start with what vibe coding is.

1. A personal budget tracker

Who builds it: individuals who've tried spreadsheets and given up.

First prompt:

Build a monthly budget tracker. I add expenses with amount, category (food, rent, transport, fun, other), date and a note. Show this month's total per category as a bar chart and a list of recent expenses. I can set a budget per category and see how much is left.

What went wrong: the chart counted every expense ever entered, not just this month, so by month two every category looked overspent. Also, amounts typed with a comma ("1,200") were saved as 1.

Fix prompt:

The chart and totals should only include expenses from the selected month. Add a month picker at the top, defaulting to the current month. Also accept amounts typed with commas or spaces and store them as numbers.

Lesson: "this month" is a rule. Say rules out loud.

2. A booking page for a small salon

Who builds it: small business owners tired of booking by phone and DMs.

First prompt:

Build a booking page for my salon. Customers choose a service, a date and a free time slot, then enter name and phone. I have a private admin page, behind a login, that shows bookings by day.

What went wrong: two customers booked the same 10:00 slot within a minute of each other, because the page only checked availability when it first loaded. A 90-minute colour booking also didn't block the slots after it.

Fix prompt:

When a customer submits a booking, check on the server that every slot it covers is still free, and reject it with "That time was just taken" if not. A service blocks its full length, so a 90-minute booking at 10:00 blocks 10:00, 10:30 and 11:00.

Lesson: anything two people can do at once needs a server-side check. See how to build a booking app for the full version.

3. A restaurant menu with a QR code

Who builds it: café and restaurant owners who reprint menus too often.

First prompt:

Build a mobile menu website for my café. Sections for breakfast, lunch, drinks and desserts, each item with name, price, short description and dietary tags (vegan, gluten-free). I need an admin page to edit items and mark them sold out. Show a QR code I can print that links to the menu.

What went wrong: nothing broke, but the menu was slow on café Wi-Fi because full-size phone photos were loaded for every item.

Fix prompt:

Menu photos are too heavy. Resize uploaded images to a maximum of 800px wide, compress them and load them lazily as the visitor scrolls.

Lesson: test on a slow connection, not just your office.

4. An equipment or stock tracker for a team

Who builds it: operations people replacing a shared spreadsheet.

First prompt:

Build an inventory tool for our warehouse team. Items have name, SKU, quantity, location and a minimum level. Staff log in and can add stock, remove stock with a reason, and see a list of items below minimum highlighted in red. Keep a history of every change and who made it.

What went wrong: the history showed "user 3" instead of names, and removing more stock than was available made the quantity negative.

Fix prompt:

Show the person's name in the history, not their ID. Don't allow a removal that would take quantity below zero; show "Only 4 in stock" instead.

Lesson: describe what should be impossible, not just what should be possible. Our guide on building an inventory app covers the rest.

5. A client portal for a freelancer or studio

Who builds it: designers, accountants, consultants and agencies.

First prompt:

Build a client portal. I invite clients by email. Each client logs in and sees only their own projects, files and invoices, and can leave comments. I log in as admin and see everything.

What went wrong: this is the most important failure on the list. The pages only showed each client their own projects, but the server returned any project if you changed the number in the address bar. Clicking around as one client never revealed it.

Fix prompt:

Check every server route that returns projects, files, comments or invoices. Each one must confirm the logged-in client owns the record, and return "not found" otherwise. Then test it: log in as client A and try to open client B's project by its ID.

Lesson: hiding something on screen is not the same as protecting it. More on this in is vibe coding safe?.

6. A launch page with a waitlist

Who builds it: founders testing an idea before building it.

First prompt:

Build a landing page for an app that helps tutors schedule lessons and collect payments. Hero headline, subheading, email sign-up, three benefits, a how-it-works section and an FAQ. Save sign-ups to a database with the date, and let me download them as CSV from a private page.

What went wrong: within days the list filled with junk sign-ups from bots, and the page had no title or description, so shared links showed a blank preview.

Fix prompt:

Add basic bot protection to the sign-up form (a hidden honeypot field and a limit of 5 sign-ups per IP per hour). Add a page title, meta description and a social sharing image.

Lesson: a public form gets found. See how to build a waitlist page.

7. A quiz app for a teacher

Who builds it: teachers and trainers who want something lighter than an LMS.

First prompt:

Build a quiz app for my class. I create quizzes with multiple-choice questions and one correct answer each. Students join with a code and their first name, answer the questions, and see their score at the end. I see a results table per quiz.

What went wrong: the correct answers were sent to the browser with the questions, so a curious student could read them in the page source. Students could also resubmit until they got 100%.

Fix prompt:

Don't send correct answers to the browser. Check answers on the server after submission. Allow one submission per student name per quiz, and show the teacher if someone tries again.

Lesson: the browser belongs to the user. Anything there can be read.

8. A small AI tool

Who builds it: marketers, writers and founders who want a focused AI helper.

First prompt:

Build a tool that turns a product description into five social media posts in different tones (friendly, expert, playful, short, long). Use an AI API. I paste the description, choose a platform, and get the posts with copy buttons.

What went wrong: the first version called the AI service straight from the browser with the API key inside the page, where anyone could copy it and run up the bill.

Fix prompt:

Move the AI call to the server. Store the API key as a secret, never in the frontend code. Limit each visitor to 20 generations a day.

Lesson: keys belong in secrets on the server. See how to keep API keys safe and how to add AI features to your app.

9. An Arabic and English business website

Who builds it: businesses in the Gulf and wider Arab world serving two languages.

First prompt:

Build a website for my interior design company in Arabic and English, with a language switch. Pages: home, services, portfolio, about and contact. Arabic should be fully right-to-left.

What went wrong: the Arabic text was right-aligned but the layout wasn't mirrored: arrows still pointed the wrong way and the menu sat on the wrong side. Phone numbers also displayed backwards in places.

Fix prompt:

In Arabic, mirror the whole layout: set the page direction to right-to-left, put the menu on the right, flip directional icons, and keep phone numbers and emails left-to-right inside the Arabic text.

Lesson: right-to-left is a layout, not an alignment. Mythex handles Arabic and other right-to-left layouts, and you can prompt in Arabic directly.

10. A tracker that becomes a phone app

Who builds it: coaches, gyms and community groups whose users live on their phones.

First prompt:

Build a workout log for my personal training clients. Each client logs in, sees the plan I've assigned for the week, ticks off exercises and records weights. I see each client's progress on a chart.

What went wrong: the web app worked, but on phones the buttons were too small to tap mid-workout and the chart was unreadable.

Fix prompt:

Design this for one-handed use on a phone: large tap targets at the bottom of the screen, one exercise per screen with big Next and Done buttons, and a simple weekly progress chart.

Lesson: if people will use it on a phone, design for the phone first. On Mythex Pro, the published app can then become an Android app for Google Play and an iPhone app sent to TestFlight; the phone app opens your published app, so each Publish updates it. See the mobile app builder page.

The patterns behind these examples

Across all ten, the failures fall into a few groups:

None of these need you to read code. They need you to test like a curious, slightly hostile user, and to describe what you see precisely.

Try one yourself

Pick the example closest to your idea, copy its first prompt, and change the details. Then use the fix prompt as a checklist before you share it. Our vibe coding prompts cheat sheet has 30 more, and how to build an app with vibe coding walks one project from idea to published app. When you're ready, start it in the AI app builder or browse templates for a head start.