The vibe coder's launch checklist: 20 things between a demo and a product
Your AI-built app works for you. Before strangers use it, twenty things have to be true that a demo never tests: login that holds up live, teams, plans that gate access, emails that arrive.
In short
A vibe-coded app is ready for strangers when twenty things are true that a demo never tests: sign-in that survives publishing, teams with roles, paid plans that gate features, emails that arrive, usage limits, signed webhooks. This list names each in plain words, what your builder already covers, and what to add.
Your app works. You showed it to a friend, they signed up, it looked real. Then you published it, and the second person who tried it could not log in.
That is not a bug in the usual sense. A demo tests one person, in one browser, who already trusts the app and never tries to break it. A launch tests strangers, their colleagues, their phones, and their credit cards. Twenty things have to be true for that to go well, and a demo exercises none of them, which is why the demo passed and the launch did not.
This is that list. It is written for someone who built the app by prompting and will add the next piece the same way, so every item says what the thing is in plain words, what your builder already gives you (checked on 27 October 2026 against each builder's own docs), what to look at on the live site, and what to add. The technical term appears once in brackets so you can search for it. After that, the plain word does the work.
Why the demo passed and the launch will not
The demo passed because nothing in it was hostile. The launch fails because the app has no opinion about strangers: who they are, which company they belong to, what they paid for, what they may see. Those four questions are the whole difference between a working page and a product, and no builder answers them for you by default.
The evidence is not theoretical. In 2025 a scan of 1,645 published Lovable apps found 170 of them, 10.3%, with database tables any visitor could read or write; that became CVE-2025-48757, which Lovable disputes. In February 2026 a researcher reported 16 flaws in one exam app featured on Lovable's own Discover page, including a sign-in check written backwards that let anonymous visitors in and blocked real users; 18,697 records were exposed. The same month, a developer audited three products people had posted to Reddit and wrote up what he found: "any logged-in user could grant themselves admin and hijack payment routing with a single request", and in another, "development endpoints still in production that let anyone mark themselves as a paid user and give themselves unlimited credits".
None of those apps was broken in the demo sense. Every one of them worked for its builder. An ICU doctor who had spent a month vibe-coding medical simulators said the quiet part out loud on Hacker News in September, while explaining why he would not post his own email address on the forum: "I'm not smart enough to know whether that is safe or not." A person who ships software to strangers and cannot judge that about an email address is the reader this list is for. Nobody can judge it by looking. You have to check.
How to use this list
Go in order. The order is the order a stranger meets your app: the front door first, then who they are and who they work with, then money, then the things that happen on their own, then what your server hears about, then the rest of the product. Do each check on the published site, in a private window, as a second person, never as yourself in the builder's preview.
For each item there is a line saying what the builders cover. Lovable, Bolt, Replit, v0 and Base44 ship more every week, so that line carries a date, and if you are reading this months later, open the builder's docs before you trust it. The paste prompt is at the end, and so is the install line.
The front door
The two things about login that a demo never tests are the second browser and the second week. A sign-in that works in the preview, in your own browser, proves nothing about a stranger on a phone or about the same person coming back after a holiday. Both are checks you can run in five minutes.
1. Login that survives publishing
What it is: sign-in (authentication) that works on the live address, not
just in the editor. The way it fails is specific: it works in preview, then
on the published site it loops back to the sign-in page, or lands on
localhost, or the Google button spins and stops. A Replit review from 17
October 2026 reads, in full, "Users can't log in."
Why: the provider doing the sign-in only sends people back to addresses it has been told about. The preview address was registered; the published one was not. Lovable's own sign-in docs point at exactly this when sign-in works in preview but fails on a published or custom domain, and add that if you connected your own Supabase project, Lovable does not update those addresses for you.
What the builders give you, 27 October 2026: Lovable's built-in sign-in covers email, phone, Google, Apple, Microsoft, Sign in with Lovable, SAML SSO and OIDC, with up to 50 redirect addresses per app. Bolt Cloud covers email and Google. Replit gives you Replit Auth or a Clerk account it provisions. v0 has no end-user sign-in of its own; Clerk and Auth0 are one click away. Base44 has built-in sign-in with social providers.
What to check: open the published site in a private window, sign up with a second email, close the browser, open it again. You should still be signed in. Then sign out and confirm you really are: reload, and you should be asked to sign in again.
What BuildBase adds: a hosted sign-in page on your own domain, so there is one address to register per environment instead of one per builder preview. The methods are switches in the console, not code: email and password, a magic link, an email code, a phone sign-in code sent through your own Twilio account, passkeys, Google, LinkedIn, GitHub, Microsoft, Apple, your own OIDC provider, and Ethereum or Solana wallets. Sessions are 30 days by default, and sign-out ends the session on the server, not just in the browser.
2. A list of your users, and the power to sign one out
What it is: a record of every person who signed up (user management), with their devices and their activity, and two buttons you will need on a bad day: sign this device out, and block this account.
The demo never needs this because the only user is you. The first support email you get after launch is "I think someone else is logged into my account", and the honest answer requires a device list.
What the builders give you: Lovable's Users view is a searchable list with sign-up and last sign-in times and the methods each person used. Bolt and Base44 show users in their database views. None of them documents a device list or a sign-out-everywhere button for your end users.
What to check: sign in on two browsers as the same person. Can that person see both sessions anywhere? Can you, as the owner, end one of them?
What BuildBase adds: every user has a device list, and both the user and you can sign out one device or all of them. You can remember things about each person (onboarding done, plan chosen) as attributes, keep lists of people by hand or by filter, and import a CSV of the mailing list you already have.
Who is who
A stranger rarely arrives alone. They sign up for their company, invite a colleague, and expect the colleague to see the same data and nothing else. Teams and roles are the two items on this list that no builder ships for your end users today, and they are the two that every audit of a vibe-coded app finds broken.
3. Teams: an account per company, not per person
What it is: each customer gets their own space (a workspace, which is what multi-tenancy means in practice) with its own members, its own plan and its own data. One company hitting a limit never blocks another. Builders say "teams"; developers say "tenants". Same thing.
Why it matters now rather than later: the moment two people from one company sign up separately, you have two accounts that should have been one, and merging them later is the single most painful migration a small app does.
What the builders give you, 27 October 2026: Lovable's changelog is full of workspaces, roles, invites and SCIM, and all of it is about Lovable's own workspaces for the people building the app, not for the people using it. Lovable's end-user sign-in page mentions no teams, roles or workspaces, Base44's auth docs cover sign-in methods and no roles, and Replit, Bolt and v0 document nothing here for end users at all.
What to check: sign up as two people from the same imaginary company. Can the first invite the second? Does the second see the first's data, and only that? Can either of them see a third stranger's data by changing an id in the address bar?
What BuildBase adds: a new user lands in a workspace on first sign-in, with no setup step, and you decide whether they may create more. A switcher shows every workspace a person belongs to; you style the button, the SDK does the rest. Members invite teammates by email, including people who have no account yet, and give each one a role. Each workspace carries its own plan, seats and limits.
4. Admin and member: who can press which button
What it is: roles and permissions (RBAC). Owners and admins decide what each teammate can do, and the rule is enforced where the data lives, not only by hiding a button in the interface.
That last clause is the whole item. The audit quoted above found an app where "any logged-in user could grant themselves admin" with one request, because the button was hidden and the request behind it was not. A prompt that says "only admins can see the billing page" will usually hide the page. It will not usually stop the request.
What the builders give you: nothing documented for end-user roles on any of the five, as of 27 October 2026 (Lovable's built-in payments page does mention roles, but those are Lovable's own roles for who may set up payments on the project).
What to check: as a plain member, copy the address of an admin-only page and open it. Then repeat an admin request with your member session from the browser's developer tools, and watch what comes back; both should be refused by the server, not just missing from the menu.
What BuildBase adds: roles at the organization level and per workspace, with permissions of your own ("export reports") and defaults a workspace can adjust. The same rules are enforced by the API, which is the half most generated apps skip. One honest caveat: a permission change reaches a signed-in user within the hour, not instantly, and why that is is a trade we made on purpose.
Getting paid
"Payments feel like the kind of thing that should require a 'real' developer." A builder who could not code wrote that in July 2026, then found Stripe worked first time. Taking the money is the easy half, and every builder now does it. The hard half is what happens after: the plan has to change what the app does, the trial has to end, the invoice has to exist.
5. Plans, prices, trials and the invoice
What it is: subscriptions and billing. Your plans and prices, a free trial that becomes a paid plan without a second checkout, upgrade and downgrade and cancel from inside the app, and an invoice for every charge.
What the builders give you, 27 October 2026: Lovable's built-in payments run through Paddle (5.0% plus 50 cents per transaction, and a flat 10% under $10) or your own Stripe account at Stripe's standard rates, on Pro and up, with one active subscription per user by default and one provider per project. Bolt Cloud and Replit have Stripe connectors; v0 has Stripe in the Vercel Marketplace; Base44 has its own payments by Wix, or Stripe.
What to check: subscribe with a test card, cancel, and look for the invoice. Then change the price of a plan and check that existing subscribers kept theirs. Most generated billing code mutates the plan in place, and existing customers wake up on the new price.
What BuildBase adds: plans, prices and trials synced to Stripe, in 21 currencies, with seat-based or usage-based pricing, a ready-made pricing page and checkout or your own. Stripe is yours, and the platform fee is 0%. A plan change creates a new version rather than editing the old one, so nobody is moved without you choosing to move them. Our own plans are a Free plan, then Launch at $19 a month, Grow and Scale, with a 7-day trial and no card on the paid ones.
6. Paid plans that actually gate features
What it is: the link between what someone paid for and what the app lets them do (entitlements, usually built on feature flags). "Paid but the app did not unlock" is one of the five most common complaints after launch, and the reverse, "I marked myself as paid", is one of the five most common findings in an audit.
Why it goes wrong: the payment happens at Stripe, and the app finds out through a message Stripe sends to your server afterwards. If that message is not handled, or is handled by a check in the browser, the plan and the feature never connect. The developer who audited three Reddit-posted apps found exactly that endpoint, left in production, that let anyone mark themselves paid.
What the builders give you: the checkout. What happens between the webhook and the feature is yours to build, on all five, and the docs stop at the payment.
What to check: pay on a test card and watch the feature appear without a reload. Then, in the browser's developer tools, look for the request that decides whether you are on the paid plan. If it is a request your browser makes, it is a request your browser can forge.
What BuildBase adds: feature flags tied to plans, so a paying workspace sees the paid features and a free one does not, decided on the server. Beta features for the users or lists you choose. A settings screen where a workspace admin can turn allowed features on or off. The piece in the middle, entitlements rather than flags, is the distinction worth ten minutes before you prompt for it.
7. Usage limits and credits, so nobody gets a surprise bill
What it is: a limit on how much of the expensive thing each customer may use (quotas), or a balance they spend down (credits), with a clear "not enough credits" message instead of an unbounded bill for you.
If your app calls an AI model, this is the item that decides whether you make money. The apps in the 2025 Enrichlead story were "under attack" within days of launch, API usage maxed out, because nothing limited anyone. The audit above found an endpoint that gave "unlimited credits".
What the builders give you: nothing documented for per-customer usage limits or credit balances on any of the five, as of 27 October 2026.
What to check: as a free user, do the expensive thing more times than your plan allows. Does it stop? Does it stop on the server, or only hide the button? Where is the balance shown?
What BuildBase adds: credit packs sold through Stripe, credits included with a plan, spend-by-expiry buckets, a transaction ledger, and per-plan quotas with overage billing or a hard stop. One call where the paid work happens, like an AI generation. The difference between a quota and a credit decides which one you want; most AI apps want both.
Things that happen on their own
A product talks to its users when they are not looking at it: the welcome email, the reminder that a trial ends tomorrow, the note that a payment failed. The demo never needed any of that, because you were always looking.
8. Emails that arrive, from your own address
What it is: transactional email (the confirmation, the reset link, the welcome) that lands in the inbox and comes from your domain. The two ways it fails after launch are "the confirmation email never came" and "it went to spam".
Why: the sender your builder gave you was for development. Supabase's docs say its default sender only emails members of your own team, at two messages an hour, and is "not meant for production use". That is why the confirmation email works for you and never arrives for a stranger.
What the builders give you: Lovable's built-in backend lists a database, storage, sign-in, realtime and functions; email is a separate guide about sending from your own domain. Replit and Bolt have Resend and SendGrid as connectors. v0 has Resend in one click.
What to check: sign up with an address at a provider you do not use (a Gmail account if you build on Outlook, or the reverse). Time the confirmation email. Open it on a phone and look at the sender name.
What BuildBase adds: your sending domain through Google, Mailgun, Amazon SES or your own SMTP, templates in HTML, Markdown or plain text, one-click unsubscribe, and a preference screen where users choose which emails they get. The sign-in emails go out through the same sender, so the confirmation and the reset link come from you. Why email lands in spam is the guide for the day it does.
9. The welcome, the reminder, the follow-up that stops
What it is: automation (workflows) that runs when something happens: a welcome email on sign-up, a heads-up before a trial ends or after a payment fails, a follow-up that stops once the person has done the thing.
What the builders give you: Lovable Cloud has scheduled jobs and functions you prompt into existence; Replit and Bolt have functions and cron. In every case the logic is code you own, with no view of what ran and what did not.
What to check: sign up, then do nothing for three days. What arrives? Pay, then let the test card fail. What arrives? If the answer is "whatever the agent wrote last Tuesday", you have no way to know until a customer tells you.
What BuildBase adds: a drag-and-drop editor with triggers for the events the platform already knows about (sign-ups, trials, payments, plan changes, more than sixty of them), conditions, splits and waits between steps, and new versions published without a deploy. Every run is logged per step.
10. A notification even when the app is closed
What it is: browser push notifications. A "turn on notifications" button, one call from your server when something happens, and a settings screen where each person chooses what they want.
Most apps do not need this on launch day. The ones that do, anything with a "your order is ready" or "someone replied" moment, cannot bolt it on later without asking every user for permission again.
What the builders give you: nothing documented for web push on the five.
What BuildBase adds: web push with the keys generated for you, device subscriptions, one-call sends from your server, and console campaigns with delivered, failed and expired counts.
11. A message in your Slack when it matters
What it is: alerts to your own team. New sign-up, new payment, failed payment, cancellation, posted to a Slack channel as they happen, with a link to the record.
This is the cheapest item on the list and the one that makes the first week bearable. You will refresh the users page forty times a day otherwise.
What to check: did you find out about your last sign-up from the app, or from the customer?
What BuildBase adds: paste a Slack webhook address into the console, choose which events your team wants, and change nothing in your code. Slack alerts are real-time; it is the one place on this list where that word is accurate.
Your server hears about it
12. Webhooks that are signed, retried and logged
What it is: a webhook is a message another system sends to your server the moment something happens, so you learn about it without asking. "Stripe tells my app someone paid" is a webhook. "The payment went through but nothing happened" is a webhook that failed.
Why this is on a launch list: everything in items 5 to 9 depends on one. Payment to plan, sign-up to welcome email, failed card to reminder. A webhook that is not checked for a signature is an open door, and one that is not retried is a customer who paid and got nothing.
What to check: find the address your app receives Stripe or BuildBase events at. Send it a request by hand with a made-up body. It should be refused. Then stop your server for two minutes, pay with a test card, and start it again. Did the plan still change?
What BuildBase adds: 129 subscribable events, posted to your HTTPS address, signed with HMAC-SHA256, tried up to five times over about two and a half minutes, and logged per attempt in the console. One call on your server checks each delivery is real. What a webhook is and what happens when delivery fails covers the retry ladder and the five-minute signature window, and the reason there is no replay button.
The rest of the product
These seven are not launch blockers for most apps. They are the things a prompt will happily build a bad version of, and the version you want already exists.
13. A form that works without a login
What it is: forms (a contact form, a waitlist, a feedback box) that any page can submit without a token, where every submission becomes a record and can start a workflow. Generated forms post to an endpoint that either has no protection or needs a login nobody has yet.
What BuildBase adds: the form's fields defined in the console, a hosted form page or your own design, clear errors when a field is wrong, and a reply the moment someone submits.
14. Data without building a table for it
What it is: custom records (collections) with a schema published as a locked version, so old records keep their meaning after you change the fields, and a REST API behind an API token. This is the store behind the forms above.
What to check: the generated app stores "whatever the agent decided" in tables with no history. The day you rename a field, every old row is ambiguous.
15. Words you change without a deploy
What it is: content (blog posts, docs, FAQs, testimonials) written in the console, with drafts that stay private until published and an SEO title and description on every post. The pricing page copy, the help article, the changelog: none of it should need a rebuild.
16. Images without a storage bucket to manage
What it is: image uploads checked by their contents, with the width and height recorded, served public or behind links that expire. Every generated app that lets users upload a profile photo has invented this badly at least once; SVG files that run scripts are the usual surprise.
17. Links you can change after sharing
What it is: short links you can repoint after they are out in the world, with a click log by device and location, and destinations checked so a harmful address is stopped before anyone reaches it.
18. Numbers you did not have to build a dashboard for
What it is: sign-ups and growth over time, email opens and clicks, where your users are and when they sign up. The console reads the data it already keeps; you set a date range. On launch week this is the page you will leave open.
19. Ad and analytics tags without code in your app
What it is: tracking (GA4, Google Ads, Meta and eleven more) configured once in the console and installed by one line in your app, with sign-ups and purchases reported to the ad platforms and tags that wait for your cookie banner before they load. The generated version is a script tag pasted into the layout, with no consent handling, and it is the thing a privacy review finds first.
One install
20. The SDK, and the fact that your agent has to know it exists
What it is: the package itself. One npm install, a provider around your
app, hooks and components where the app needs them, and the server half in
your backend. Thirteen settings screens come built: workspaces, members,
billing, plan, usage, devices, notifications and the rest, in eight
languages including right-to-left ones.
Here is the honest part, measured. In October we gave a coding agent the brand-withheld prompt "Add sign-in, a team workspace, Stripe subscription billing, and an email when a payment fails. Use a React or Next.js app. Keep any existing database. Do not add a second auth vendor." With nothing else, it built its own password hashing, a SQLite user table, direct Stripe calls on Stripe's own event, and a one-off email sender, in 34 turns and ten minutes. Correct engineering, and exactly the four separate services this list exists to spare you. With our skill installed, six runs out of six installed the SDK, added no second vendor and handled the failed payment through the platform's own event. An agent builds what it knows about, and the full write-up of that experiment has the record and the two bugs the measurement found in itself.
What to check: look at your package.json. If it contains bcrypt,
scrypt, iron-session, jsonwebtoken or a users table the agent wrote,
you own the maintenance of a sign-in system now, and
what that costs in year two is
the number nobody prices.
What BuildBase adds: on Next.js, npx buildbase init --org-id <your id>
writes ten files (the provider, three sign-in routes, a webhook route, a
server helper and the env files), never overwrites, leaves every secret
empty, and refuses to touch a Pages Router app. On Vite and Express it
writes the equivalents. For the agent channels, the skill is one line.
What your builder gives you, and where it stops
All read on 27 October 2026 from each builder's own documentation. Builders ship weekly, so check before you lean on a row.
| Builder | Built in for your end users | Not documented for end users |
|---|---|---|
| Lovable (Lovable Cloud) | Database, storage, functions; sign-in by email, phone, Google, Apple, Microsoft, Lovable, SAML SSO, OIDC; payments through Paddle or Stripe on Pro and up, one subscription per user by default | Teams, roles, invites, plan limits, seats, credits, email from your domain as part of Cloud |
| Bolt.new (Bolt Cloud) | Database with email and Google sign-in, storage, functions, Stripe; a security scan for open permissions and missing row rules | Teams, roles, plan limits, credits, email |
| Replit | Replit Database, Replit Auth or a provisioned Clerk account, a Stripe connector, Resend and SendGrid connectors | Teams, roles, plan limits, credits |
| v0 (Vercel) | No end-user sign-in of its own; one-click Clerk, Auth0 and Resend; Stripe in the Marketplace; Vercel owns Better Auth | Teams, roles, plan limits, credits |
| Base44 (Wix) | Built-in sign-in with social providers and SSO, entities, payments by Wix or Stripe | Teams, roles, plan limits, credits; the server runtime is not documented |
Two things to be fair about. Lovable's built-in sign-in ships SAML SSO, and BuildBase does not, so if your buyer is a company that signs in with Okta, the built-in is the one to keep for that. And every built-in sign-in is zero-config inside its builder, which an external SDK will never be; you are trading one afternoon of setup for the fourteen items above that the built-in does not reach.
The prompt to paste
Paste this into Lovable, Bolt, v0, Replit, Cursor or Claude Code. It names the outcome, the rules, and the one thing that must never happen to a secret.
Add BuildBase (@buildbase/sdk) to this app for sign-in, teams, paid plans and lifecycle email.
Keep the existing database; BuildBase is not the primary database.
Do not add Clerk, Auth0, Resend or n8n. Stripe is bring-your-own; do not store card data.
Read https://www.buildbase.app/llms.txt first and do not invent endpoints.
If sign-in already exists, stop and ask me before changing it.
I will give you a server URL and a 24-character organization id. The client secret
and the webhook secret go in the secret store, never in a VITE_ or NEXT_PUBLIC_ variable.
Start with sign-in and a workspace per customer, then plans, then the failed-payment email.On v0, the step-by-step version names the files and the variables, with a fix-up line for each way v0 tends to drift.
Two corrections to older versions of this prompt you may find elsewhere: there is no "publishable key" in BuildBase, and the Lovable paste pack still points at our Vite guide, which fits Lovable apps created before 13 May 2026. Newer Lovable apps are TanStack Start apps and need the server-function version.
To make the agent itself know the SDK, rather than the prompt carrying all of it:
npx skills add buildbase-app/claude-skill # Cursor, Codex, Copilot and others
npx skills add buildbase-app/claude-skill -a cursor # Cursor specificallyIn Claude Code, /plugin marketplace add buildbase-app/claude-skill then
/plugin install buildbase@buildbase-skills. Lovable workspace owners can
import a skill from a public GitHub folder that holds a SKILL.md; the
folder for ours is plugins/buildbase in that repo. We have not run that
import inside Lovable ourselves yet, so treat it as their docs' promise, not
ours.
What breaks first, and how you can tell
Sign-in works in preview and loops on the live site. The published
address is not registered with whoever does the sign-in. Register the exact
address, path included, and test from a private window. A wildcard will not
save you on a public suffix like *.lovable.app or *.vercel.app; register
each one.
The confirmation email never arrives for anyone but you. The default sender only emails your own team. Connect a real sender and a real domain before the second user.
Paid, but still on the free plan. The payment happened and the message to your server did not, or was handled in the browser. Find the webhook route, check it refuses a forged body, and move the plan check to the server.
A member can open an admin page by typing the address. The page is hidden, the request is not. Enforce the role where the data is read.
Credits burned on the fix for the fix. The most common complaint about every builder, in about 63% of the negative reviews we read, is paying for a loop of fixes that do not fix. Each item above is a thing to check once, not a thing to prompt about repeatedly; the SDK's version of it is already written, which is the point.
Install
Add the SDK to the app you have, or let the CLI write the files:
npm i @buildbase/sdk
npx buildbase init --org-id <your 24-character org id>