# Letting people sign in to your app

The moment your app has anything that belongs to one person rather than
everyone — a booking, a saved list, an order history, a members-only page — it
needs accounts. People sign up, they sign in, they come back a week later on a
different phone, and some of them forget their password.

Hatchik gives Claude a ready-made, correct version of all of that. You do not
have to ask for it by name. Say "people should be able to make an account", or
"only logged-in people should see this", and Claude uses it.

## What you get

- Signing up, signing in and signing out.
- Staying signed in for a month, on each device, including after you change
  and republish your app. Nothing signs anybody out by accident.
- **A forgotten-password link that works.** Someone types their email address,
  gets a link, sets a new password and is back in.
- A "confirm your email address" message when someone signs up, so a typo gets
  caught while they still remember what they typed.
- Passwords stored properly, and protection against someone sitting there
  guessing.

## Why the forgotten-password part matters most

There is no support desk here — not at Hatchik, and not at your business
either. If somebody cannot get into their account, there is nobody for them to
email about it. So the only acceptable answer is that they can fix it
themselves, in a minute, without you.

That is the whole reason this is worth doing properly rather than improvising
it. Everything else about a sign-in either works or visibly does not. A broken
reset link works fine until the day somebody needs it, and then it costs you
the customer.

## Where your customers actually are

**In your own database, in your own project.** Not in Hatchik.

Hatchik hosts the database and sends the emails, and that is all. It never sees
anybody's password, it is not the thing your customers sign in to, and there is
no "sign in with Hatchik" — on purpose, and it is not coming. Your customers
are your relationship, not something you rent.

Practically, that means: when you download everything from your project — which
you can do at any time, without asking anyone — your customers' accounts come
with it. If you ever want to move off Hatchik, you take them with you.

## What your customers see

A sign-in page that looks like the rest of your app, because Claude builds it
in your style. The only page that comes ready-made is the one the emailed link
lands on, and Claude can restyle that too.

The emails come from your business name, with replies going to your own
address. Tell Claude where replies should go — someone replying to a password
email is someone who needs you.

## Things worth knowing

**Passwords have to be at least ten characters.** Three or four ordinary words
you will actually remember is both easier and far harder to guess than
something with a symbol in it. The hundred or so most-guessed passwords are
refused outright.

**Your draft and your live site keep separate customers.** They are separate
databases. Someone who signs up while you are testing on the draft does not
exist on the live site. That is what you want — you can try things without real
people seeing them — but it surprises people, so it is worth knowing.

**Going back has a cost here.** For a plain website undo is free: you say "put
it back how it was" and your site goes back. For an app it puts the whole
database back — accounts included. Anybody who signed up since would be gone,
anybody who changed their password since would find the old one working again,
and every other record written since goes with them.

Claude will not do that quietly. Ask to undo and it stops, tells you how many
people and how much else it would affect, and waits for you to say yes. If it
cannot work out a number it says so and still waits. If it is a lot of people,
download everything first — that takes seconds and it is the version of your
customer list from right now.

**"Sign in with Google" is more trouble than it looks.** It needs you to set up
an account with Google's developer service, fill in a consent screen, and get
it reviewed once you have more than a hundred people. Worse, it breaks every
time your web address changes — so the day you point your own domain at your
app, nobody can sign in. Email and a password have none of those problems.
Claude can do it if you insist, but it will tell you all that first.

## When something goes wrong

Say what you see, in your own words: "nobody can sign in", "the reset email
never arrived", "it says my password is wrong and it isn't".

- If an email did not arrive, Claude can look up exactly what happened to it —
  whether it was sent, refused, or bounced — before guessing.
- If the sign-in stopped working after a change, Claude can put the app back.
- If your app will not start at all after a change and says something about
  accounts, that is deliberate. The accounts code checks itself every time your
  app starts, and refuses to run if something has weakened it. It happens on
  your locked draft, before your live site is touched. Ask Claude to put the
  accounts file back the way Hatchik gave it and to make its changes around it
  instead.

## What Hatchik will not do

- It will not be your customers' login provider, hold their passwords, or let
  them use one account across several people's apps.
- It will not read, list or export your customers for anyone but you.
- It will not offer a "log in as this customer" button. If you need to see
  what somebody sees, ask Claude to build that into your own app, where you
  control it.