Capability · Managed backend
Database, auth, email and payments — pre-wired as code
When your app needs data, sign-in, transactional email or payments, the code for it is written in from a catalogue of vetted bricks. Connecting the accounts behind that code is a separate, explicit step.
the brick writes the code — you connect the account
What you get
Built to be trusted
The hardest part of shipping a real app is usually the backend: a data layer to write, sign-in to get right, mail to get sending, payments to plumb through. None of it is typed out afresh on every build. The agent works from a catalogue of vetted bricks, and reaching for one writes real code into your project — the files, the npm dependencies, the environment keys, the SQL migrations and the notes saying where each piece mounts. What a brick does not do is conjure the account behind it: connecting Supabase, Stripe or Resend is its own step, and for Stripe and Resend it is your account by default.
POSTGRES
A real data layer
Ordinary Postgres on Supabase, reached through a vetted access brick — a service-role helper on the server, an RLS-gated client in the browser, and the migrations that create the tables.
AUTH
Sign-in handled
The auth brick arrives whole: a session provider and useUser() hook, an email login and sign-up form, a route guard, sign-out, and a migration giving every new user a profile row under row-level security.
PAYMENTS
Take money
The payments brick writes the Checkout Session endpoint, the client redirect and a signature-verified webhook — against your own Stripe account, so the money settles with you.
Details
What's included
| Service | Provider | What you get |
|---|---|---|
| Data layer | Supabase | Schema, migrations and a vetted access layer written into the project |
| Authentication | Supabase | Session provider, login form, route guard and a profiles migration |
| Database security | Postgres | Row-level security forced on every table, plus the indexes its policies filter on |
| Transactional email | Resend | Generated sending code — you bring the key and the verified sending domain |
| Payments | Stripe | Checkout endpoint, redirect and signed webhook, on your own Stripe account |
Five layers written from vetted bricks, onto providers you can keep or take elsewhere.
In practice
A real flow, end to end
A single request can pull in several bricks at once. Here the auth, payments and email layers are written into the project without leaving the editor.
Add a paid membership: users sign in, pay monthly,
and get a welcome email after checkout.Writing the auth brick — session, login form, route guard…
Writing Stripe checkout + a signature-verified webhook…
Generating the Resend welcome email…
✓ Membership flow live in the preview; connect Stripe and Resend to charge and send for real.How the backend stays trustworthy
- The code targets established providers — Supabase, Stripe and Resend — not bespoke infrastructure you would have to trust blindly and could never leave.
- A brick only goes in when your app actually needs it, so nothing is added speculatively.
- Every brick lands in your repository: its files, its dependencies, its migrations and the environment keys it expects, all yours to read and change.
- Connecting a live account is explicit and separate. Supabase can run on our account or on yours; Stripe and Resend run on yours by default, so payouts and sending reputation stay with you.
- Because it is a standard Postgres database, your data is real and portable rather than locked in a proprietary store.
FAQ
Common questions
Put managed backend to work today.
Start free — no credit card, nothing to configure. Managed infrastructure and monitoring are included.