Basecamp 2: Vibe Coding

Authentication is identity validation: proving you're a legitimate user at all — the login, the email verification, the password check. Authorization is access level: given that you're valid, which tier of features do you get?

The cleanest everyday example is ChatGPT itself: logging in is authentication; whether you're on Free, Plus, Pro or Enterprise — and therefore which models and limits you get — is authorization. Every app with tiers, roles or admin panels is running both checks on every request.

An API is the bridge between front end and back end, and endpoints are its addresses. Every function an app offers — post a reel, like, comment — has its own URL. Pressing the button sends an HTTP request there with a payload (your video, your caption) and your auth details; the back end runs its checks and code, and returns a response the front end turns into 'Posted!'.

Once you see this, the AI economy makes sense too: a model API is just another endpoint. OpenAI exposes its models at a URL, your app sends a request with a key, and you pay per call from console credits. The 'AI feature' in any app you build is one more endpoint conversation.

Third-party integrations are the off-the-shelf services and libraries you slot in instead of building everything: Supabase or Convex for the managed back end (database, auth, storage, edge functions), Tailwind CSS and shadcn/ui for the front-end look. The movie analogy: you rent the VFX house, you don't found one per film.

The session's most practical corollary: naming these in your prompt is what separates experienced builders' output from generic output. Every unstyled vibe-coded app ships with the same purple-gradient look; say "use Tailwind and shadcn/ui" — or screenshot a UI you admire and ask for it in those terms — and the same platform produces something that passes as production.

An SDK (software development kit) is how a vendor's product becomes usable inside your app: OpenAI, Anthropic and Gemini all ship one, and 'add AI to my app' concretely means 'wire in one of these'. Libraries like LangChain and LangGraph sit a level deeper — they're the code layer that tools like n8n are built on top of.

The workflow shift the session teaches: as a non-technical builder you don't study any of this. You paste the documentation URL into Claude Code or Cursor and ask it to build the feature against those docs. The agent reads the SDK; you review the result. Hand-building LangChain pipelines is explicitly what you should not be doing.

The back end has to physically run somewhere, and that machine is the server — the editing suite in the movie analogy. While you're developing, your own laptop plays the role: 'localhost' is your machine serving the app to itself. The moment other people need to reach it, you rent an always-on machine from AWS or GCP instead.

Vibe-coding platforms quietly bundle this: the reason your build is instantly live at a *.lovable.app URL is that Lovable is hosting it on their machines. Convenient — and one more form of the platform lock-in this session keeps flagging, which is why the serious stack graduates to Vercel or Railway on a repo you own.

When you have an app idea, the untrained move is to open a builder and type. The framework inserts four free steps first. Research: your competitors' pricing pages are a goldmine, because those comparison tables are each company's own answer to 'what will customers pay for'. Screenshot them, let ChatGPT extract and de-duplicate the whole feature universe. MVP: pick 2 core features plus 1 AI differentiator. PRD: have ChatGPT write the spec a product manager would hand engineers. Prompt: feed the PRD plus the vendor's own prompting guide back to ChatGPT so it emits a first prompt in the dialect your builder wants.

Only then do you build. The sequence works in any domain with any tool because it separates thinking (free, in chat) from execution (metered, in the builder) — and produces a paper trail you can reuse when you switch platforms.

The feature map from your research will be huge — that's the point of making it, and the trap. An MVP deliberately ships almost none of it: two core features that make the product usable at all, plus one AI differentiator that answers 'why this instead of the incumbents'.

For Task AI: projects-and-tasks structure, board/list status views, and an AI project generator that turns messy input — meeting notes, transcripts — into structured projects and tasks. The third item is load-bearing: without it you've built 'just another project management software'; with it you're in the AI-native category where the ecosystem is heading.

ChatGPT and Claude let you iterate endlessly at no marginal cost: refine the feature map ten times, rewrite the PRD, argue about scope. Lovable, Replit and Emergent charge credits for every interaction — including the exploratory ones that produce nothing.

So the discipline is architectural: all research, planning and PRD work happens in the chat tool; only the finalized plan crosses over. The builder receives a finished prompt and spends its credits on what it's uniquely good at — producing the app. Cross that boundary sloppily and you pay builder prices for thinking.

Lovable used to partner with Supabase; now it bundles its own back end — database, auth, storage, edge functions, even AI models — as Lovable Cloud, and actively pushes it. External Supabase still works, but the wiring is deliberately harder: in the live build, secrets wouldn't stick and edge-function deploys demanded a terminal, until the trainer moved the whole build to Lovable Cloud mid-session.

The trade-off is clean: Lovable Cloud buys speed and zero setup for MVP validation, at the price of margin on every call and ecosystem lock-in; your own Supabase costs setup friction and buys control plus a generous free tier. Every platform — Bolt, Replit, Emergent — is running the same play for the non-technical majority, so this decision recurs no matter which builder you choose.

A Supabase table without RLS answers queries from anyone with your project URL and a valid session — which, in a vibe-coded app, means any user can fetch the whole users table: names, phone numbers, emails. The front end not *showing* the data is no protection; the endpoint still serves it.

The fix costs one checkbox: enable automatic RLS at project creation, and every table starts protected, with access defined by explicit policies. The session's warning wasn't hypothetical — Lovable-built apps have shipped with open tables and leaked data. This is the authorization half of the auth lesson, made concrete.

.env is where real secrets live: API keys, service-role tokens, database credentials. .gitignore lists it so git can never ship it to GitHub. .env.example is the public twin — it names every key the app needs with placeholders, so a collaborator (or a coding agent) knows what to supply without ever seeing values.

The reflex completes the system: when a key leaks anyway — and the session leaked one live, pasting the Supabase service-role key into chat — you don't hope, you rotate. New key in the dashboard, old one dead. Since a service-role key bypasses RLS entirely, that reflex is the difference between an oops and a breach.

The graduation path is the deliberate end of the vibe-coding story: Lovable's GitHub connect creates a real repository from your project; git clone brings it to your machine; VS Code opens it; Claude Code continues the work. From that point the platform is optional — you iterate locally where marginal cost is your subscription, not per-interaction credits.

This is also the lock-in antidote for everything else in the session: Lovable Cloud, bundled hosting, credit pricing all lose their grip once the code lives in a repo you own. The platforms know it too, which is why the sync exists but is never the button they point you at.