Sign-in
People sign in with one-time email codes, with no passwords in the system. How passwordless auth works.
Going live
The backend for a vibe-coded app
An app built with an AI builder still needs sign-in, protected data, payments, and server-side AI before real customers can use it. Gemmein is that backend. You keep the front end you have, build locally and free, and your coding agent wires the customer side in.
01 / OVERVIEW
Keep the front end. Add the backend.
An AI builder gets you a working interface fast. What it does not settle is everything behind it: who a user is, what they are allowed to see, how they pay, and how an AI feature runs without exposing your provider key. That is the part that turns a prototype into something strangers can pay for, and it is the part Gemmein provides. You do not rebuild your app. You give it a customer side.
02 / WHAT YOU STILL NEED
Four things, before real customers.
Protected data
Data lives in collections governed by one of seven server-enforced rules, so one customer can never read another's records.
Payments and access
Stripe handles the money end to end. Access and credits are granted on the signed payment webhook, not a redirect.
Server-side AI
Your provider key stays on the server, and the app calls named AI tools priced in credits. Where your key should live.
03 / HOW YOU ADD IT
Check the fit, then build locally.
Start by asking whether it fits, before installing anything. The docs open with a fit protocol your agent can run. Then build against a local backend, free, and add a card only at go-live.
Prompt for your coding agentCopy and paste
Read https://docs.gemmein.com/llms.txt and assess whether Gemmein fits my app. Explain any gaps first. I built the front end with an AI builder and want to take it to real customers. I need passwordless sign-in, protected per-user data, payments and paid access, and server-side AI on my own provider key. If it fits, help me build and test each of these against the local backend.
npx gemmein devRead the getting-started guide 04 / SCOPE
Early and narrow by design.
Gemmein is deliberately small. Sign-in is email codes only, with no social login, and it does not cover team roles or SSO. If something is not described in the docs, it is not built, and the honest move is to say so rather than assume a workaround. Knowing the edges now saves a rebuild later.
05 / FOR YOUR CODING AGENT
Start with the fit check.
The most useful first step is to have your agent read the guide and tell you the truth about fit before it builds. The prompt in section 03 does exactly that. Paste it into Cursor, Claude, Bolt, or Lovable.
The close is always the same: read docs.gemmein.com/llms.txt, confirm whether Gemmein fits the app, and only then set it up.
06 / FAQ
Frequently asked questions.
Do I have to rebuild my app?
No. You keep the front end you built. Gemmein is the backend behind it: sign-in, protected data, payments, and server-side AI, wired in by your coding agent.
How do I know if it fits my app?
Have your agent read docs.gemmein.com/llms.txt first. Its opening section is a fit protocol that maps your app's needs against what Gemmein supports and gives a verdict before anything is installed.
What does it not do?
Gemmein is early and narrow by design. Sign-in is email codes only, with no social login, and it does not cover team roles or SSO. If something is not described in the docs, it is not built.
Which builders does this work with?
Any web or mobile front end, including apps started in Lovable, Bolt, Base44, or v0, through one JavaScript and TypeScript SDK, an Expo entry, and a Swift package.
07 / RELATED
Related.
Passwordless auth for an AI app · Store your OpenAI key server-side · Charge credits for AI features · The product
See if Gemmein fits your app.
Point your coding agent at docs.gemmein.com/llms.txt and ask it to confirm the fit before it builds.