The AI Learning Hub Journal

Accounts, Passwords and the Locked-Out Customer

Two kinds of people — and the product must enforce the differencekeep using the sign-in your platform provides — this lesson is everything around it that nobody mentionsENFORCED BY THE PRODUCT, NOT HIDDEN BY THE SCREENTHE GROOMERsees everything — every booking,every customer, every dogA CUSTOMERsees their own bookings —and nobody else’sthe screen hides it: no button — but the files would still hand it overthe product enforces it: the request itself is refusedask the AI directly: if a customer tries to reach another customer’s booking, is it refused — or was there just no button?the prototype almost certainly does the hiding; the product needs the refusingstill true from Vibecoding, and not aged a day: never build your own sign-inTHE LOCKED-OUT CUSTOMER — THE RUNNING COST NOBODY BUDGETS FOR· somebody is locked out most weeks — not carelessness, just what 200 real people and their passwords do· the reset lands late, in spam, or at the old address from two phones ago· from their side there is no nuance: the business cannot take bookings· they phone the groomer, and the groomer phones youTHE DRILL, WHILE NOTHING IS WRONGlock yourself out on purpose · request the resetwatch where it lands and how long it takeson a phone, in a hurry — the way a customer wouldreset email is your problem even when the platform sends it — the customer will never phone the platformTHE NEVER-DO LIST — TWO HABITS THAT WILL TEMPT YOUNEVER LOOK UP OR SET A CUSTOMER’S PASSWORD‘I’ll set it to something and read it out’feels helpful — never do ita properly built system will not evenshow you their password — be gladthe moment you can read passwords,every leak becomes your faultNEVER SHARE ONE ADMIN SIGN-INhand over the existing admin sign-in andtwo people become one personnobody can tell who changed a bookingwhen someone leaves, changing the locklogs everyone outseparate people, separate sign-insSEND THE RESET, EVERY TIME — AND ONE SIGN-IN PER PERSON, FROM DAY ONE OF TWOwho sees what is a fact of the product, tested on purpose — not a hope about which buttons the screen shows
A screen that does not show other people’s bookings is not the same as a product that refuses to hand them over.

Two Kinds of People

Vibecoding's final module said never build your own sign-in, and that advice has not aged a day — use the sign-in your platform provides. This lesson is about everything around sign-in that nobody mentions. Start with the biggest: your product now has two kinds of people. The groomer needs to see everything — every booking, every customer, every dog. A customer must see only their own bookings and nobody else's. Here is the part that catches people: the product must enforce that difference, not merely hide it. A screen that does not show other customers' bookings is not the same as a filing system that refuses to hand them over. The prototype almost certainly does the first; the product needs the second. Ask the AI directly: if a customer tries to reach another customer's booking, is the request refused — or was there just no button for it?

  • Never build your own sign-in — still true; this lesson is everything around it
  • The groomer sees everything; a customer sees only their own bookings
  • The product must enforce the difference, not have the screen politely hide it
  • Ask: is another customer's booking refused, or just missing its button?

The Locked-Out Customer

Sign-in has a running cost nobody budgets for, and it is not money. With 200 customers, somebody is locked out most weeks. Not because your customers are careless — because that is simply what 200 real people and their passwords do. A reset email arrives late, or lands in spam, or goes to the old address from two phones ago, and now the customer cannot book. From their side, that means the business cannot take bookings. Here is the uncomfortable rule: reset email is your problem even when the platform sends it. The customer will not email the platform; they will phone the groomer, and the groomer will phone you. So test the journey while nothing is wrong: lock yourself out on purpose, request the reset, watch where it lands and how long it takes. Do it on a phone, in a hurry, the way a locked-out customer actually would.

  • 200 customers means someone is locked out most weeks — plan for it as normal
  • Reset email is your problem even when the platform sends it
  • A locked-out customer experiences it as 'the business cannot take bookings'
  • Lock yourself out on purpose and time the journey back in

What You Never Do

Two habits will tempt you, and both belong on a never-list. The first: looking up or setting a customer's password. When someone is stuck, the helpful move seems to be 'I'll set it to something and read it out'. Never. A properly built system will not even show you their password, and you should be glad — the moment you can read passwords, every leak becomes your fault, and every customer who reuses that password elsewhere is exposed by you. Send the reset instead, every time. The second: sharing one login. When the second groomer arrives, the tempting move is to hand over the existing admin sign-in. Now two people are one person: you cannot tell who changed a booking, and when someone leaves, changing the lock logs everyone out. Separate people, separate sign-ins, from the first day there are two of you.

  • Never look up or set a customer's password — send the reset, every time
  • If you can read passwords, every leak is your fault
  • Never share one admin sign-in when the second groomer arrives
  • Shared logins mean nobody can tell who did what, and leaving means locking out everyone

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.