What is vibe coding? A plain-language glossary for founders and their lawyers

You built an app by describing what you wanted to an AI, and now people keep using words at you: RLS, DPA, PITR, env vars, migrations. Your developer says them like you should know them, and your lawyer nods along without knowing them either. Here’s a plain-language glossary so you can follow the conversation and ask the right questions.

What is vibe coding?

Vibe coding is building software by describing what you want in plain English to an AI tool, which writes the actual code for you. Instead of typing every line yourself, you prompt: “add a login page,” “make the button blue,” “store bookings in a database.” Tools like Lovable, Cursor, Bolt, and Claude Code do this. The name comes from working off the vibe of what you want rather than the mechanics of how it’s built.

It’s genuinely powerful. A non-developer can ship a working app in a weekend. The catch is that the AI writes code that looks right and often runs fine in a demo, but it doesn’t automatically handle the boring, critical parts: backups, security, what happens under load. Those are the parts that matter when real users show up, and they’re the reason the rest of this glossary exists. For a fuller take, see what Stackbastion is and who it’s for.

The terms, in plain language

Environment variable (env var)

A setting stored outside your code, like a password or an API key. Instead of writing your secret Stripe key directly into the app (where anyone could find it), you store it as an environment variable and the app reads it at runtime. Why it matters: if secrets are in the code instead of env vars, they can leak publicly. Keys in code is one of the most common and most expensive mistakes in AI-built apps.

API key

A secret password that lets your app talk to another service (Stripe for payments, OpenAI for AI features, a mail service for emails). Anyone who has your key can use that service and bill it to you. Why it matters: a leaked API key can run up thousands in charges before you notice. If a key was ever pasted somewhere public or left in your code, treat it as compromised and generate a new one.

RLS (Row-Level Security)

A database rule that controls which rows of data each user is allowed to see. “Row-level” means it works per record: user A can see their own bookings, but the database itself blocks them from seeing user B’s, even if the app has a bug. Why it matters: without RLS, the most common serious flaw in vibe-coded apps is that any logged-in user can read everyone else’s data. RLS makes the database enforce privacy, not just the front end.

PITR (Point-in-Time Recovery)

The ability to restore your database to any exact moment, like “9:14am, just before the bad change,” rather than only to last night’s snapshot. Why it matters: if someone deletes the wrong thing at 2pm, a nightly backup loses everything since midnight. PITR lets you rewind to 1:59pm and lose almost nothing. It’s the difference between “we lost a day” and “we lost a minute.”

Backup vs. restore

A backup is a saved copy of your data. A restore is actually bringing that copy back to life. They sound like the same thing but they’re not: a backup you’ve never restored might be corrupt, incomplete, or unrecoverable, and you won’t find out until the worst possible moment. Why it matters: the only backup worth trusting is one you’ve restored and checked at least once. “We have backups” is not the same as “we can recover.”

Migration (database migration)

A controlled change to the structure of your database, like adding a new column or a new table. Migrations are how the database evolves as your app grows. Why it matters: done carelessly, a migration can lock up or wipe data on a live app. Done properly, it’s a safe, reversible step. When your developer says “I need to run a migration,” they’re reshaping the data, so it should be backed up first.

DPA (Data Processing Agreement)

A legal contract between you and any company that stores or handles personal data on your behalf, like your hosting provider or database host. It says how they’ll protect that data and use it only as you instruct. Why it matters: under GDPR, if you collect personal data from EU users, you’re legally required to have a DPA with each processor. No DPA with your data host means you’re out of compliance the moment you collect a single EU email. See DPA vs. terms of service for why the two aren’t the same.

GDPR

The EU’s data protection law. It governs how you collect, store, and use personal data (anything that identifies a person: name, email, IP address) from people in the EU. Why it matters: it applies to you if you serve EU users, no matter where your company is. The basics are a lawful reason to hold the data, a privacy policy, DPAs with your processors, and a plan for when someone asks to see or delete their data.

Environment (dev, staging, production)

The different copies of your app. Production is the live one real users touch. Staging is a near-identical copy for testing changes safely. Dev is where a developer builds. Why it matters: you want to test changes in staging before they hit production, so a mistake breaks a test copy instead of your live business. Many vibe-coded apps have only production, which means every change is a live experiment.

Connection pooling

A way of sharing a limited number of database connections across many users, instead of opening a new one for every request. Why it matters: databases allow only so many connections at once. AI-built apps often open one per request and never close them, so the database hits its limit and everything stops the moment traffic picks up. Pooling (with a tool like PgBouncer) keeps that from happening on launch day.

A note for the lawyer in the room

If you’re the legal advisor being handed a vibe-coded app to review, the terms that carry legal weight are DPA, GDPR, and, underneath them, RLS and backup/restore. The technical question “can users see each other’s data” is also a legal question about data breaches. The question “can we recover deleted data” ties to data integrity duties. You don’t need to read the code. You do need to confirm those four are handled, in writing.

Or, we do it for you

If reading this list mostly told you how many of these you haven’t sorted out, that’s normal, and fixable. A free Stackbastion audit checks your app against every term above and hands you a plain-language report of what’s solid and what’s a gap, with no jargon and no obligation.

FAQ

Is vibe coding “real” programming?

Yes, the output is real code running a real app. The difference is who wrote the lines: an AI, guided by your prompts, instead of a person typing them. That makes building faster and more accessible, but it doesn’t remove the need for the production basics in this glossary. The app doesn’t know it was vibe-coded, and neither do your users or the GDPR regulator.

Which of these terms actually matter for a small launch?

For any launch with real users: backup/restore, API keys and env vars, and RLS. Those three cover “can we recover,” “are our secrets safe,” and “can users see each other’s data.” If you serve EU users, add DPA and GDPR. The rest (staging, pooling, PITR) matter more as you grow, but they’re worth understanding early so you know what you’re deferring.

My developer uses these words but I still don’t get it. Is that a problem?

It’s a signal to slow down, not a reason to feel behind. A good developer can explain each of these in one sentence a founder understands, exactly like this glossary does. If yours can’t, or won’t, that’s worth noting: the person running your app should be able to tell you plainly what’s protecting your data. Ask them to define these terms in your words.

Do I need to memorize all of this?

No. Bookmark it and pull it up when a term comes up. The goal isn’t to make you a developer, it’s to let you follow a technical conversation and ask “do we have RLS?” or “have we tested a restore?” without feeling lost. Those two questions alone will catch most of the serious problems in a vibe-coded app.