Hatchik help → Letting people sign in to your app

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.

The same page as plain text, for an AI or anything else that prefers it: /docs/accounts.md