A real backend, born with your app
Database, sign-in, files, functions, secrets, email — every Kliv app starts with all of it, created and managed by the AI as you build. Nothing to provision, nothing to wire up, nothing to keep in sync.
Cloud backend
Not a backend service you wire up
Most AI builders generate a frontend and hand you a checklist: sign up for a database here, an auth provider there, paste the keys, write the glue. Every seam in that stack is yours to maintain. Kliv's backend is born with the app — one system, so the same conversation that builds your pages also writes your migrations and your access rules, and the rules hold everywhere.
What every app is born with
This isn't a feature list you enable piece by piece. It's the standard equipment under every Kliv app — here is what's running before you've finished describing page one.
A database with rules of its own
Your data lives in your own database, and privacy is enforced at the row: a rule like "clients read only their own projects" is a property of the data, checked on every query — not an if-statement someone has to remember to write in every page.
Sign-in and identity
Accounts, sessions, roles, and organizations exist before your first page does. Your users can be individuals or whole companies — and sign-in reaches well past passwords, which gets its own section below.
A file store with access rules
Uploads, images, and documents carry rules of their own: private, shared per organization, or gated behind a purchase. A forwarded link opens nothing the rules don't allow — sharing is a decision, not an accident of URLs.
Server-side functions, typed
When logic must run on the server — a calculation, a callback into another tool, a nightly job — the AI writes real TypeScript against a typed SDK the compiler checks. Functions run on demand, on events, or on a schedule.
Secrets in a vault
API keys and credentials live in a vault, never in code the browser can see. Functions read them at runtime, and nothing sensitive ever lands in your source.
Email that carries your name
Delivery and templates are part of the backend — the mail your app sends is branded as your app, written once, and sent without a third-party mail service to configure.
Managed as you build
The part no backend service does: the AI maintains all of this as a side effect of building. Describe a feature and the schema change arrives as an ordered, tracked migration; the access rules evolve with the pages that need them. The backend follows the app, because they were never separate.
The standard equipment
Six pieces, one system — each one already wired to the others.
Your own database
Row-level security enforced on every query — per-user privacy is a property of the data, not a habit your code has to keep.
Sign-in & identity
Accounts, organizations, and roles — plus Google and Facebook sign-in, passkeys, and two-factor for your users.
The file store
Files with access rules of their own — private, per-organization, or behind a purchase. Links alone open nothing.
Typed server-side functions
Real TypeScript against a compiler-checked SDK — on demand, on events, or on a schedule.
The secrets vault
Keys and credentials out of your code and out of the browser — functions read them at runtime.
Email delivery
Templates and delivery built in — mail that carries your app's name, not a vendor's.
Sign-in, built in
Most builders give you email and password and call it identity. Kliv gives your app's users the sign-in they expect from real products — and it belongs to your app: your flow, your branding, your records.
Email & password
Accounts, verification, and resets — the table stakes, handled properly.
Sign in with Google & Facebook
One-tap sign-in with the accounts your users already have.
Passkeys
Phishing-resistant sign-in with Face ID, Touch ID, or a security key — no password to steal.
Two-factor authentication
TOTP codes from any authenticator app, for the users who want a second lock on the door.
Organizations & roles
Teams, roles, and organization walls — the structure the database's rules are written against.
Your users, your records
Every account is a row in your own database — segment them, export them, or erase one on request. The relationship is yours.
Common questions
Is the backend a separate service I have to manage?
No — that's the point. It's born with the app and managed through the same conversation that builds it. There's no dashboard to provision, no keys to paste on day one, and no second system drifting out of sync with your code.
Who writes the database migrations?
The AI does, as a side effect of building. Describe the feature and the schema change arrives as an ordered, tracked migration — readable if you want to look, applied in sequence so the database's history is as legible as the app's.
How is per-user privacy actually enforced?
At the row. Every query returns only what the signed-in user is allowed to see, because the rule lives on the data itself — so a bug in a page can't leak what the database refuses to hand over.
Can my users sign in with Google?
Yes — Google and Facebook, alongside passkeys and TOTP two-factor. And it's your app's sign-in, not a third-party widget: your flow, your branding, and user records that live in your own database.
Where do API keys and credentials live?
In the vault. Functions read them at runtime; they never appear in code the browser can see, and nothing sensitive lands in your source history.
Can I get my code and my data out?
Yes. Your app's source syncs two-way to your own Git repository, and the data is your own database — export it any time. Kliv's bet is that you stay because it's good, not because leaving is hard.
Describe your app. The backend comes with it.
Built-in means built together: the checkout, the agent, and the tests all run on this same backend — one set of rules, enforced everywhere.