Your phone number is the account

Watch someone book an appointment on a website they have never used. There is a specific moment where their face changes, and it is not the price. It is the account.

They wanted a haircut on Thursday. They are now inventing a password, for a website they will visit twice, which must contain a number and a special character. Some percentage of them close the tab here — and every one of those was a booking your host had already earned.

Guests do not get a password

Not "password optional". There is no password. There is nothing to forget, nothing to reset, nothing to reuse from another site that has already been breached.

A guest types their phone number and gets a code on WhatsApp. That is the login. If we have not seen the number before, the account is created in the same motion — they will never know a signup happened, because from where they are sitting, one did not.

The phone number is the identity. Not an attribute of the account, not a recovery method bolted on afterwards. The account *is* the number.

Which is convenient, because we needed it anyway

Here is the part that made this an easy decision rather than a brave one.

We were always going to send booking reminders on WhatsApp, because in India that is where messages are read. So we always needed a verified phone number. Every guest was going to give us one regardless.

Once you notice that, a password is just a second credential doing a job the first one already does — worse, and with a support burden attached. The verified number proves they are them. What is the password adding? A reset flow, a hashing decision, and an email you now also have to collect.

We deleted the whole branch.

If you already need a verified phone number to do your job, a password is a second lock on the same door, and you are the one carrying both keys.

The reasoning, such as it is

Hosts get exactly one door

Hosts sign in with Google. Only Google. There is no email-and-password option, no OTP fallback, no "or continue with" list.

This annoys a certain kind of person and we are keeping it, for two reasons.

The first is that a host account is not a guest account. It holds a calendar, a payout destination, and other people's personal details. Google does authentication better than we will — hardware keys, device checks, suspicious-login detection, an entire security organisation. Offering a weaker second door next to it does not add convenience. It just means every attacker uses the weaker door, and now our security equals the worst option we offer, not the best.

The second is arithmetic. Every additional auth path is not one more thing to build — it is one more thing to be correct in forever, at every intersection with every other path. Two paths is not twice the work; it is the work plus every place they meet. Sessions, linking, recovery, revocation, the lot.

The rule we wrote down

Never build a third auth flow.

It is in our project rules, in those words, because we know exactly how this goes. A partner needs SSO. A host is locked out of Google. Someone suggests a magic link, just for this one case. Each is reasonable on its own, and four of them mean nobody can say how anyone logs in.

Two flows. Guests have a number. Hosts have Google. Everything else is a request to make the door bigger, and the door is not the problem.