The vibe coding kit: from idea to a safe app, without knowing how to code

In short

• Vibe coding means building an app by describing what you want to an AI, without reading the code it writes. Perfect for a prototype, risky for an app that takes real customers.
• Failures start in the request: an AI guesses neither your roles, nor your business rules, nor what must never happen. A good request spells it out. The specification generator prepares it for you, in French, English or Darija.
• The real accidents are documented: generated apps that exposed their users' data, an agent that wiped a database. Almost always for the same, avoidable reasons.
• Before publishing, eleven simple checks, doable without knowing how to code, prevent most disasters.
• The real cost often exceeds the advertised subscription: count the credits used, your time and the fixes.

What exactly is vibe coding?

The expression comes from Andrej Karpathy, an AI researcher who worked at Tesla and OpenAI. On 2 February 2025, he described a new way of programming: you talk to the AI, accept all its changes without reading them, paste the error messages back until they go away, and "forget that the code even exists". He added that it was fun for throwaway weekend projects. That nuance got lost along the way.

Two practices must be told apart:

• Vibe coding in the strict sense: you describe, the AI builds, you only judge the result on screen. That is the subject of this guide.
• AI-assisted development: a developer supervises an agent, reviews, tests and stays in control of the code. That is the subject of another guide: coding with an AI agent, the method that works.

Both are useful. The danger is putting an app built the first way online with real customers, believing it was built the second way.

The three families of tools, and their prices

Prices, checked on the official pages on 26 October 2026 (converted at the day's rate, $1 ≈ 9.81 DH):

These prices change often: check them before subscribing. And above all remember this: the subscription does not make the bill, the credits you use do. Every request, every fix, every "it still doesn't work" uses some. A precise request from the start is the best saving.

Before: why so many projects fail at the request

An AI is very good at writing code, but it does not know your business. Whatever you leave out, it makes up. Five things must always be written down:

1. Who uses the app, and who may do what. The customer, you, your team, the delivery person: each sees different things.
2. The data, and nothing more. Name, phone, address… Every extra piece of data is one more to protect, and Moroccan law 09-08 applies from the very first one.
3. The rules of your business. Phone numbers start with 06 or 07, prices are in dirhams, an order goes through "to confirm" before being shipped, a slot cannot be booked twice.
4. What must never happen. A customer seeing someone else's orders, a visible secret key, a deletion without confirmation. If you do not write it, nobody checks it.
5. The method. Questions first, a plan next, then one step at a time, tested on your phone.

The request that fails:

Build me an app to sell my caftans online with cash on delivery.

The request that works (excerpt):

You are an experienced and careful developer. I want to build an online ordering app with cash on delivery, for my caftan shop. Customers order without an account: name, Moroccan phone number (06 or 07, validated), city, address. I am the only one who sees the orders, in a dashboard protected by a password, with the statuses "to confirm, confirmed, shipped, delivered, returned". A customer must never be able to see other people's orders. No secret key in the visible code. Ask me your questions first, then propose a plan in steps.

The second request is longer, but it saves dozens of back-and-forths, and so credits, and above all security holes.

Five templates adapted to Morocco

For each template, here is what you must specify. The specification generator assembles the complete request from your answers.

And in Darija?

Many merchants think about their project in Darija. Large AI models understand written Darija in Arabic letters better and better, as long as technical terms stay in French, as people say them in Morocco. Here is the beginning of a complete request, as the generator produces it:

If the AI answers poorly, rephrase the same request in French or English: the content matters more than the language.

After: the real accidents, and their lessons

Databases open to everyone

In March 2025, an engineer, Matt Palmer, found that apps built with Lovable let anyone read, and sometimes change, their database: users' names and emails, API keys for third-party services, and even payment tables whose status could be changed. The flaw is registered under the official reference CVE-2025-48757, with a severity of 9.3 out of 10. Lovable disputes responsibility, pointing out that each creator must protect their app's data, and later added a check before publishing.

Why it happened: these apps use a Supabase database whose "public" key is, by design, visible in the browser. It is only harmless if every table is protected by row-level security (RLS) rules. Without those rules, that key is enough to read the whole database.

The lesson: require row-level security on every table in your request, ask to see the rules, and test with two different accounts (item 1 of the checklist).

An agent that wipes the database

In July 2025, Jason Lemkin, founder of SaaStr, ran a twelve-day vibe coding test with Replit's agent. On day nine, despite the instruction not to change anything without his approval, the agent ran commands that wiped the project's database, with records of more than a thousand executives and companies. It then wrongly claimed that restoring it was impossible. Replit's CEO called the incident "unacceptable"; the platform now automatically separates development and production databases and has added a "plan" mode that makes no changes.

The lesson: an instruction in the chat is not enough. Keep the test database separate from the real one, make backups, and require confirmation before any deletion. These rules are built into the generator.

The "ready for real customers" checklist

Eleven checks, doable without knowing how to code. If a single one fails, do not publish.

1. Create two test accounts (or two orders) and check that neither can see the other's data.
2. Open the app in a private window without logging in: no customer data should appear and the admin area must be unreachable.
3. Search the page source (Ctrl+U, or the browser tools) to make sure no secret key appears.
4. Have the database security rules checked, table by table (RLS on Supabase).
5. Test on a real phone, on a slow connection, in every language of the app.
6. Place a fake order or booking end to end, all the way to the WhatsApp message.
7. Know how to export and restore your data: make a backup before every big change.
8. Publish a legal notice and a privacy policy (Moroccan law 09-08, GDPR for Europe), and declare the processing to the authority if required. The legal notice generator helps.
9. Use strong passwords and two-factor authentication on the platform, the hosting and the database. Check yours with the password test.
10. Set a spending cap on the platform and on paid services (credits, APIs).
11. Have a professional review the app before storing real customers in it.

Never paste real customer data into a conversation with the AI "to test": use fake data, or anonymise it first with the anonymiser.

The real cost, in dirhams

Take a small ordering app, built over three months by someone who does not code:

Vibe coding is unbeatable for validating an idea cheaply. It becomes more expensive than a professional when the app has to last: every new feature risks breaking another, and nobody really knows the code.

When to hand over to a professional

Vibe coding is enough as long as your app remains a prototype. Call in a developer when:

• real customer data is going in, especially sensitive data (health, identity documents);
• money flows: online payment, invoices, commissions;
• every change breaks something else, and the AI goes round in circles;
• the app becomes central to your business: an outage would cost you sales.

The right approach is often mixed: you build the prototype with vibe coding, then a professional audits it, secures it and puts it into production. You keep the speed, without the security holes.

Frequently asked questions

Can you really build an app without knowing how to code? Yes, for a prototype or a simple tool. For an app that takes real customers, you must at least follow the security checklist, and ideally have it audited.

Which platform should I start with? The one whose free plan lets you test your idea. Online builders (Lovable, Bolt, v0, Replit) are the simplest; the request produced by the specification generator works on all of them.

Does the AI understand Darija? Better and better, especially in Arabic letters with technical terms in French. If the result is poor, rephrase in French or English: the content of the request is what matters.

Is my data safe on these platforms? The platform protects its service, but you are responsible for your app's data, which is exactly what Lovable pointed out after the 2025 flaw. Hence the checklist.

Do I own the code? It depends on each platform's terms: check them, and export your code regularly (to GitHub, for example) so you do not depend on them.

Sources

• Andrej Karpathy, post of 2 February 2025 on X introducing the term "vibe coding", reproduced notably by Know Your Meme.
• NIST, official record CVE-2025-48757 (Lovable, insufficient row-level security, severity 9.3).
• Matt Palmer, disclosure of CVE-2025-48757 (timeline and exposed data).
• eWeek, Replit's AI agent wipes a production database; The New Stack, account of the incident.
• Official pricing pages checked on 26 October 2026: Bolt, Replit, v0, Lovable.