Add real accounts and payments to a vibe-coded app
Every vibe-coded app hits the same wall: sign-in is faked, "data" is localStorage, and payments are a button that doesn't do anything. The fixes people usually reach for — bolting together an auth provider, a database, and a payments service — mean three vendors, three dashboards, and a security model you now own. There's a shorter honest path.
The port is always the same three moves: fake sign-in → email codes · localStorage → safety-ruled records · dead button → your own Stripe.
›Read docs.gemmein.com/llms.txt — does Gemmein fit my app? Verdict first, then take it live.
Paste it to the AI you already build with — Claude Code, Codex, Cursor, Bolt — it reads the guide and answers for your app.
1
Sign-in stops being pretend
Users get a one-time email code — no passwords exist anywhere in the system, so there's no password database to breach and nothing for your AI to configure wrong. Your app calls two SDK functions; sessions, revocation, and the owner's admin view are already handled.
2
localStorage becomes records with rules
Each collection gets exactly one plain-English safety rule — private, shared, community, and four others — enforced on the server. "Each user sees only their own notes" is a property the platform enforces, not a hope your frontend filters correctly. Your AI proves it with live calls before anyone real arrives.
3
The dead button charges money — yours
Name a plan or product, paste a Stripe Payment Link, and checkout() sends the signed-in buyer to Stripe with everything wired. Gemmein records who paid and what it unlocks; refunds and cancellations flow back automatically. The money lands in your Stripe account — Gemmein never holds, moves, or processes it.
Questions
That's the intended path. Paste docs.gemmein.com/llms.txt to the AI that built your app — it assesses fit against your actual code first, asks you only the business questions, and does the wiring against a free local backend (npx -y gemmein dev) before anything goes near the internet.
It's on each user's device, so there's nothing to migrate server-side — the honest move is a one-time import: on a user's first sign-in, your app reads their local data and writes it to their own private records. Your AI can wire that in a few lines, and each user's history survives.
You do — deliberately. With Gemmein, every payment lands in your Stripe account and the customer is legally your customer. Merchant-of-Record platforms (Paddle, Lemon Squeezy) flip that trade: they become the seller of record, their name is on the card statement, and your customer is contractually theirs — in exchange they carry the tax filing. Both are legitimate. Selling digital products to EU consumers can create VAT duties from the first sale, and at heavy international volume a Merchant of Record genuinely earns its cut. For most independent founders under the UK's £90,000 VAT threshold, with Stripe Tax able to calculate what's owed, you're deciding whether to hand over the customer relationship to avoid paperwork you may not have yet. Gemmein never holds, moves, or processes money either way — that's Stripe's job, in your account.
Web apps only — no native mobile SDKs today. No team or workspace visibility scopes, no per-user record permissions, no carts or physical goods, no multi-seller payouts, no hosted functions or cron (your server-side code runs on your own host with a secret key). If something isn't in the builder guide, it isn't built — the guide says so out loud rather than letting an AI invent a workaround.
Build anywhere. Launch with Gemmein.
›Read docs.gemmein.com/llms.txt — does Gemmein fit my app? Verdict first, then take it live.