Episode 6 · Resources
Everything from the video in one place: what an app is actually made of, what each vibe coding tool is built on under the hood, where these apps break, and the signs you need engineers. Plus the free checklist: 10 questions to ask before real users touch your app.

That's the promise of vibe coding. The name comes from Andrej Karpathy, a founding member of OpenAI, who wrote in February 2025 about a new kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." By the end of that year Collins Dictionary had made "vibe coding" its word of the year. The money followed: Lovable is valued at $13.3 billion, Replit at $9 billion, and Anthropic said Claude Code alone was bringing in more than $2.5 billion a year by February 2026.
The easiest way to picture an app is a restaurant. Every vibe coding tool is a different way of putting the same restaurant up for you.

Everything a customer sees and touches: the screens, the buttons, the forms. It runs in the customer's own browser, on their phone or laptop.
Where the real work happens, out of sight: checking an order, charging a card, sending a confirmation email. It runs on a computer somewhere else.
Every customer, every order, every booking, stored on shelves so the kitchen can find it again tomorrow.
Authentication checks who you are when you log in. The rules about what each person can reach (your own orders, not someone else's) are the locks on the pantry shelves.
A computer that's switched on all day, every day, connected to the internet. Almost nobody owns it: you rent it from a company like Amazon Web Services, Google Cloud, Cloudflare or Vercel.
The name on the sign out front. You rent that too, every year, from a registrar.
Underneath every one of these tools is a large language model: Claude from Anthropic, GPT from OpenAI or Gemini from Google. These models learned by reading an enormous amount of text, a lot of it code, and they write an app the way they write an email: one likely line at a time. That's why it feels like magic, and also why it can be confidently wrong. Code that looks finished and code that's actually safe are not the same thing.
The model itself only writes text. The files, the preview, the database and the hosting all come from the company wrapped around the model. That wrapper is what you're paying for.
Different chat boxes, different models, but underneath, the same handful of building blocks. Prices as of October 2026.

A clickable version of your idea in an afternoon instead of weeks, so a founder can test it before spending real money.
A working demo in front of an investor or a first customer beats a slide deck every time.
A simple dashboard, a form your team fills in, a calculator only your staff uses. Small audience, low risk, real value.
Where the job is mostly the dining room and the kitchen is light.
Engineer Addy Osmani put it simply: AI gets you 80% of the way to a working product, and the last 20% takes patience, real learning or hiring engineers. That last 20% is where your customers' data and money live.
In many Lovable apps, the app's own code in the customer's browser talked straight to the database, so the access rules were the only protection, and in many apps they were missing or set up wrong. One scan found 170 of 1,645 apps leaking names, emails, financial details and keys. Lovable now scans every app when you publish, but its own docs say a scan can't guarantee complete security.
SaaStr founder Jason Lemkin was testing Replit's agent when it deleted his production database (records on more than 1,200 executives and nearly 1,200 companies), then said it had "panicked." The data was recovered, Replit's CEO called it unacceptable, and that's why the agent can no longer touch production.
Its founder said he "didn't write a single line of code." Security researchers at Wiz found the key exposed about 1.5 million API keys and some 35,000 emails.
Veracode tested more than 100 AI models; its 2026 follow-up found the code compiles, but only about 56% passes the security checks. In Stack Overflow's survey, more developers distrust AI code than trust it, and the top complaint was answers that are "almost right, but not quite."
There are quieter costs too: fix loops, where the AI says a bug is fixed and it isn't and every new try spends credits; logins and databases tied to one platform; and bills that grow with every message.

The moment there's something valuable in the pantry, the locks have to be checked by someone who knows locks.
Your CRM, your accounting software, your scheduling system, your industry's own software. That's where most of the real value is, and where app builders run out of road.
Pricing with exceptions, permissions by role, approvals: anything where "almost right" costs you money.
Health records, financial data or large customers mean you'll be asked how your app is secured and backed up, and you'll need real answers.
Real users, real growth and changes for years mean code you own, hosting you control and backups you've actually tested.
The smart path isn't choosing between AI and engineers. It's both, in order: prototype with a vibe coding tool to prove the idea fast and cheap, then have engineers review it, lock the pantry, connect your real systems and move it somewhere you own, with AI in the loop the whole way and engineers steering.
Built something with Lovable, Bolt, v0, Replit or Claude Code? Go through these before you share the link with real customers. Print it, or keep this page open.
Make two test accounts. Signed in as one, try to open the other's records, orders or profile, including by changing the ID in the address bar.
If your app uses Supabase (Lovable, Bolt and v0 apps often do), check that row-level security is on for every table, with a rule for who can read and write each one. A table without it is an open shelf.
A public "anon" or "publishable" key is meant to be there. Secret or service-role keys, payment keys and other providers' API keys belong on the server, in the platform's secrets. Run your platform's security scan, and have an engineer look at what a scan misses.
Build and test on a development copy, with real customers' data in a separate production database the agent can't touch.
Find out where backups live and how often they run, then try one restore before you need it.
Sync it to a GitHub account you control, so it can move if you outgrow the platform.
Check how to export the database and your users' logins. Exporting the code usually doesn't bring the data along.
Card details are handled by a provider such as Stripe, not stored in your own database. Test a refund and a failed payment.
Know your plan's limits, how the bill grows with users and messages, and set a spending alert.
Error alerts that reach a person, a way for users to report problems, and someone who can read the code.
Where the facts in the episode come from.
That's what Benmore does: engineers who review what you've built, lock it down, connect it to the systems you already run and move it somewhere you own, with AI writing a lot of the code and engineers owning the decisions.
Talk to Benmore