Build313
← Scalability Beyond Lovable

Advanced AI Build Night · Scalability Beyond Lovable · Cheat sheet

Scalability Beyond Lovable

Scalability Beyond Lovable — cheat sheet

The one idea: Lovable is a launchpad, not a home. Tonight you take ownership of your code and move it onto infrastructure you control — no rebuild required. A Lovable app is just React + Vite + Tailwind + Supabase; there's nothing magic to escape.

The graduation checklist (4 steps)

  • [ ] 1. Own the code — connect GitHub, push the repo. You now hold the source.
  • [ ] 2. Run it local — clone, install (bun install or npm install), set env vars, bun dev.
  • [ ] 3. Own the backend — your own Supabase project + keys; sanity-check RLS is ON.
  • [ ] 4. Own the deploy — import the repo into Vercel/Cloudflare, set env vars, point a domain.

Env-var map — what Lovable hides vs. what you now set

| Variable | Lovable | You (own deploy) | | --- | --- | --- | | VITE_SUPABASE_URL | injected for you | set in host + .env | | VITE_SUPABASE_ANON_KEY | injected for you | set in host + .env | | any API keys | hidden in platform | move to env vars, never commit | | build command | run automatically | bun run build (or npm run build) | | output dir | handled | dist (Vite default) |

Stay-vs-go — when graduating is premature

| Signal | Stay on Lovable | Graduate now | | --- | --- | --- | | Still iterating fast on UI | yes | no | | Hit a feature ceiling Lovable won't do | — | yes | | A client/employer must own the code | — | yes | | Cost or lock-in is a real problem | — | yes | | "Might need it someday" | yes (stay) | no (don't graduate on a hunch) |

Most apps should stay on Lovable longer than builders think. Graduate for a reason, not for a vibe.

Top 5 gotchas + the fix

  • Hardcoded keys in source → move every key to an env var; rotate anything that was committed.
  • Missing env vars in the host → the build is green but the app is blank; set VITE_* vars in the host dashboard, then redeploy.
  • Supabase RLS left off → your tables are world-readable; turn Row Level Security ON and add policies before you point a domain at it.
  • Build-vs-preview drift → "works in dev, breaks in prod" usually means an env var or a build-only import; run bun run build && bun run preview locally first.
  • Wrong build/output settings on the host → set framework to Vite, build to bun run build, output to dist.

Where real scale lives next (not tonight)

  • Caching, DB indexes, and query tuning when traffic shows up.
  • Cost monitoring so a bill never surprises you.
  • CI (lint + build on push) and a real git/team flow.

Glossary

  • Env var — a secret/config value set outside the code (.env locally, host dashboard in prod) so keys never live in source.
  • RLS — Supabase Row Level Security; per-row rules deciding who can read/write. Off = public.
  • CI — automated checks (lint, build) that run on every push so broken code never merges.
  • Build-vs-preview — dev is the live-reload server; build + preview is the production bundle. Test the second before you ship.

Template library

Copy a starting point, paste it into your assistant's instructions, then make it yours.

Map an exported Lovable repo before you change anything.

Explain this inherited codebase
I just exported this app from Lovable and I now own the code. Walk me through it like I'm inheriting a project.

Tell me:
- The stack and how the app boots (entry file, router, build tool).
- Where the Supabase client is configured and which env vars it reads.
- The main routes/pages and what each one does.
- Anything that looks Lovable-specific or that I'll need to change to run it on my own host.

Keep it concrete — name real files and line ranges. Don't change anything yet.

Catch secrets baked into source before you push public.

Find hardcoded keys & move them to env
Scan this codebase for any hardcoded keys, secrets, tokens, URLs, or credentials that should be environment variables instead.

For each one:
- Show the file and line.
- Tell me whether it's safe to be public (e.g. a Supabase anon key) or must be rotated (anything secret).
- Propose the env-var name (use the VITE_ prefix for anything the client reads).

Then make the edits: replace each value with the env var, and list anything I need to rotate because it was already committed.

Give the project a clean, documented env setup.

Set up env config + .env.example
Set up environment-variable config for this Vite app so it runs on my own machine and my own host.

Do this:
- Create a .env.example listing every variable the app needs, with placeholder values and a one-line comment each.
- Make sure the real .env is gitignored.
- Point the Supabase client (and anything else) at import.meta.env variables instead of hardcoded values.
- Tell me exactly which vars I need to set locally and in my host (Vercel/Cloudflare) dashboard.

Stop broken code from merging once you own the repo.

Add a basic CI check (lint + build)
Add a minimal CI workflow to this repo that runs on every push and pull request.

Requirements:
- GitHub Actions, single workflow file.
- Install dependencies (detect whether this project uses bun or npm and use that).
- Run lint, then run the production build.
- Fail the check if either step fails.

Keep it simple and fast — no deploy step, no matrix. Show me the final workflow file and where it goes.

Knowledge-file starter

Fill in the brackets, save it as a PDF or text file, and upload it as your assistant's knowledge.

Knowledge file
# .env.example — copy this to .env and fill in your own values

# Supabase — your OWN project (Settings → API in the Supabase dashboard)
VITE_SUPABASE_URL=https://your-project-ref.supabase.co
VITE_SUPABASE_ANON_KEY=your-anon-public-key

# Add any other keys your app uses below (use the VITE_ prefix for anything
# the browser reads). Never commit the real .env — only this example file.
# VITE_SOME_API_KEY=

# ---------------------------------------------------------------------------
# Graduation checklist (plain text — tick as you go)
#
# [ ] 1. Own the code   — connect GitHub, push the repo
# [ ] 2. Run it local   — clone, install, set .env, run the dev server
# [ ] 3. Own the backend— your own Supabase project + keys, RLS on
# [ ] 4. Own the deploy — import to Vercel/Cloudflare, set env vars, add domain

Build 313 · Advanced AI Build Night · Presented by JD Fiscus