Your app only writes what makes it different

Every vibe is built on one design decision, and once you see it, the rest of the platform makes sense: generated code is responsible for exactly one thing — what makes your app different. Its interface, its data shapes, its logic, its personality. Everything an app needs but that doesn't make it distinctive — identity, permissions, the security boundary, the database, serving, the social graph — is platform substrate, outside the generated code's scope.

This isn't a convenience layer bolted onto a normal stack. It's a different division of labor, and the division is the security model.

The prototype wall

Most AI coding tools share a failure mode we call the prototype wall. You get something that looks real in minutes — that part genuinely works. But the path from there to production runs through everything the generator also wrote for you: hand-rolled login, permission checks scattered through the UI code, API keys pasted where users can find them. The demo was real; the trust boundary was improvised. You discover which one you have when real users show up.

The wall isn't bad luck. Traditional stacks make each app responsible for its own trust boundary, so a code generator has to generate security-critical code — precisely the code that language models are worst at getting reliably right, and that the person prompting is least equipped to review.

Vibes doesn't help you climb the wall. It removes it. The security-critical layers were never in the generated code to begin with, so there is nothing to harden later — the prototype and the production app are the same artifact. That matters at every skill level, not just for beginners: for an experienced developer it means a radically smaller attack surface and far less code standing between "works on my machine" and "safe to share."

What the platform owns

Identity and authentication. Sign-in, sessions, and your handle live in the platform chrome, outside your app's iframe. Your app learns who the visitor is as a verified fact; it never sees a password, a token, or an OAuth flow. There is no auth code in a vibe to get wrong — not because it was generated carefully, but because it was never generated.

Authorization and sharing. Who can read or write each document is declared in one place — access.js — and enforced by the platform at read and write time, not by if statements in your UI. A missing check in App.jsx can't leak a document, because App.jsx was never the gate. The concepts (channels, grants, roles, handles) are mapped in the access model, and the sharing UI — invites, requests, public toggles — is platform chrome too: Sharing & Access.

The sandbox boundary. Each app runs on its own origin, inside a locked-down iframe, against a runtime version the platform pins per deploy. App code can't reach the platform's cookies, other apps, or the control plane. The serving side of this story is in How Your App Is Served.

Your data. Apps talk to their databases through the Fireproof API — name a database, put documents, render live queries. On Vibes that API is backed by Firefly, the platform's own database: deliberately simple, built to make the API fast and easy to use rather than to be a database product. No connection strings, no ORM, no migrations, no server credentials in generated code — databases are addressed by name, and every read and write passes through your access rules on the platform side.

The backend. Ship a backend.js and your app has a server side — webhooks, scheduled jobs, per-vibe secrets, server-side AI — with outbound network access governed by platform trust rules rather than anything the app (or its owner) declares for itself. The whole surface is in Your App Has a Backend.

The social graph. Follow and follower relationships are platform data, managed once in your account settings and usable from any vibe. An app says "visible to my followers" or "just my mutuals" as an audience in its access rules, and reads relationship state through the useSocial() hook — without generating follow buttons, edge storage, request queues, or privacy handling. Concepts and the full surface: The Social Graph.

Serving. Server-rendered first paint with your public data already in it, an edge cache with honest freshness rules, instant cutover on deploys — production-grade delivery with zero configuration in app code. Details: How Your App Is Served.

Why this is safer, not just easier

• The generator never writes security-critical code. Language-model failure modes — plausible-but-subtly-wrong logic — land in your features, where they're visible and fixable, not in the trust boundary, where they hide until exploited.
• Enforcement is uniform and audited once. Every vibe gets the same identity, access, and sandbox machinery, and a platform fix reaches every app on the next deploy pin — no per-app patching, ever.
• Fail-closed by construction. What your app doesn't handle, it can't mishandle: no keys to leak, no session logic to botch, no cookie scoping to misconfigure. Access-gated reads fail closed at the platform when in doubt.

Why this is faster to build

The prompt budget goes where it counts. You never spend generation — or review — on login screens, permission middleware, or database plumbing, and the generator never produces a subtly different copy of that boilerplate per app. Features that are multi-week projects on a traditional stack land as a sentence in a prompt or a few lines of access.js: multi-user sharing, anonymous submissions, a backend with secrets, role-gated views. The patterns cookbook is full of production examples that are each about a page of code — because the page of code is only the different part.

What this means for how you build

• Write the feature, not the infrastructure. If you find yourself prompting for a login page, a permissions system, or somewhere to store an API key — stop. Ask for the feature you actually want; the platform lane for it already exists (sign-in is ambient, access.js gates data, per-vibe secrets live server-side).
• Going to production is publishing, not a migration. There is no hardening checklist between the app you prompted and the app you share — same artifact, same enforcement, from the first minute.
• What's still yours. The platform can't make your feature logic correct, stop you from deliberately making data public, or vouch for third-party APIs you call. The boundary it owns is who can reach what — what your app does within that boundary is the part you're here to make.

Where to go next

• The access model — the concepts behind every sharing decision, with the traps labeled.
• Your App Has a Backend — the server side every vibe gets.
• How Your App Is Served — the path from URL to pixels.
• Patterns cookbook — the principle doing real work.

Wondering where a specific responsibility falls — your code or the platform? Ask in Discord or open an issue at VibesDIY/use-vibes.