Your demo runs fine on your laptop. A real app is different: it holds what people cannot afford to lose, their saved work, who they are, and their money. So it has to remember what they made after a restart, know them when they return, and charge them without ever mishandling a card. Two of those three you must never build yourself, and this chapter gets you all three plus the rules that keep them from ending your app.
8.2.1Store data that survives
A demo keeps its data in memory, so closing it erases everything. A real app must persist what people create: write it to a database that survives a restart, a deploy, and a crash. The chapter on modeling your data covers the shape that data takes.
Treat what you store as the most valuable thing you hold, because it is the one part you cannot regenerate. Back it up, and never run a change that could erase it.
8.2.2Accounts: never roll your own auth
The moment people log in, you are doing authentication: proving each person is who they claim to be. It looks simple and is not. Password hashing, session tokens, password resets, two-factor, breach checks: each is a place to get security subtly wrong, and one mistake exposes every account at once.
So do not build it. Use an authentication provider, Auth0, Clerk, Supabase Auth, or your framework's own vetted library, whose whole job is getting this right and patching it as attacks change. You wire your app to it and never store a password yourself.
8.2.3Payments: never touch card numbers
Payments have a stricter rule: a raw card number must never reach your server, and you are not allowed to store one. Handling cards safely is governed by a standard called PCI, and meeting it yourself is a compliance project, not a feature.
So you never touch the card. A payments provider like Stripe gives you a form that sends the card straight from the user's browser to them, then hands back a token, a harmless reference you keep in place of the card. You charge the token; the provider carries the risk.
DON'T let these reach your server
a card number, its CVC or expiry
a password you hashed yourself
login tokens you invented
DO store only safe references
the auth provider's id for each user
Stripe's token in place of the card
8.2.4Protect what users trust you with
The pattern is the same for all three: let specialists hold the dangerous parts. The database keeps the data, the auth provider holds identities, the payments provider holds cards, and your app stores only references to them. Give each the least access it needs, encrypt anything sensitive, and back up what you cannot regenerate.
This prompt hands your case to your agent:
Act as a senior engineer wiring up what a real
app needs beyond a demo: persisted data, user
accounts, and payments. Enforce two hard rules.
Never roll our own authentication: choose a
provider (Auth0, Clerk, Supabase Auth, or the
framework's vetted library) and wire to it, so
we never store a password. Never let a raw card
number reach our server: use a payments provider
(Stripe) so the card goes browser to provider
and we store only its token. For each of the
three, tell me what we store, what the specialist
holds, and the least access it needs. Then list
the backup and encryption steps for the data we
cannot regenerate.
My app: what it stores, who logs in, what they pay for:
Do this now: paste the prompt with your app's specifics and let your agent wire each of the three to a specialist, then confirm your server holds references, never a password or a card.
