# 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.

- Source: https://www.buildbase.app/guides/vibe-coded-app-launch-checklist
- Section: Guides
- Author: Dharmendra Jagodana
- Published: 2026-10-27

## 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](/blog/why-permissions-refresh-hourly) 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](/blog/entitlements-are-not-feature-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](/blog/quotas-are-not-credits) 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](/guides/transactional-email-landing-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](/blog/what-are-webhooks) 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](/blog/what-a-coding-agent-builds-when-nobody-tells-it-otherwise)
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](/blog/ai-generated-code-maintenance-cost) 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.

```text
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](/guides/add-sign-in-teams-and-paid-plans-to-a-v0-app)
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:

```bash
npx skills add buildbase-app/claude-skill            # Cursor, Codex, Copilot and others
npx skills add buildbase-app/claude-skill -a cursor  # Cursor specifically
```

In 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:

```bash
npm i @buildbase/sdk
npx buildbase init --org-id <your 24-character org id>
```