Social login vs email login: what 13 site plans chose

Use email login as the base and add social login, usually Google, when customers sign in on their own phones and return often. In 13 AI site and app plans read on 21 October 2026, 8 offered both Google and email, 3 offered email only, and 2 had no sign in. The 11 site databases built carried the same choices.

Where the numbers come from

Every OneCraft plan that keeps data includes a login line, such as “login: email, google”. The table reads those lines from OneCraft’s development project on 21 October 2026, one plan per business and job type, the latest completed pipeline run: 11 websites and 2 apps. It then checks the Google sign in flag on each site database that exists, 11 in all, every one a schema in OneCraft’s pool.

Caveats: n is 13 plans and 11 databases, too few to call a trend; the briefs were written by the team, and several said whether to offer Google; all ran on one environment, and the planner changed during the week. The yoga studio briefed three times on 20 October has three databases, one with Google off, so the database column counts runs, not businesses. This measures what was planned and switched on, not what visitors chose, because these were test sites with no real visitors.

What the plans chose, and why

Email and Google, 8 plans. Two yoga studios and the yoga app, a pilates studio, a ceramics shop, a kayak hire, a running club and a sourdough course. In each, members of the public sign in on their own phones to book, buy, post or learn, and come back often. A one tap Google button cuts the step where most sign ups stall, inventing a password. The running club even planned a home page band saying “sign in with Google to join the feed”.

Email only, 3 plans. A pottery studio, a branding agency’s client portal and a cleaning company’s staff app. The portal’s users are clients with work addresses; the staff app’s users are employees the owner adds. Neither needs the convenience of a consumer account, and a single method is simpler to support. The pottery plan simply did not ask for it.

No sign in, 2 plans. A dog hotel and a dog walker, whose briefs asked for information pages, a shop teaser and contact. With nothing for a visitor to come back to, they needed no accounts and no database.

What each method costs you

Concern	Email and password	Google sign in
Sign up steps	Email, password, often a confirmation email	One tap with an existing Google account
Forgotten passwords	Needs a reset flow	Handled by Google
What the site learns	The email typed	A verified email and a name
Who it leaves out	No one with an email address	People without, or not wanting to use, a Google account
Setup	Built into most auth services	An OAuth client with redirect addresses

Whichever you choose, the sign in method decides who someone is, not what they may see. Access rules in the database do that, and they must be written for every table. Read what OAuth is for how the Google button works and what a magic link is for the passwordless option, plus row level security.

Three questions before you choose

1. Who signs in, and on whose device? Customers on their own phones favour a one tap button. Staff on a shared tablet, or clients on a managed work laptop, may not be able to use a personal Google account at all, and email works everywhere.
2. How often do they come back? A class pass holder signing in weekly gains the most from skipping a password. Someone who orders once a year will have forgotten either way, so a dependable reset email matters more than the button.
3. What will you do when someone loses access? A customer who signed up with Google and later closed that account needs a way back in. Keeping email as the base gives you one, because every account still has an address the business can confirm.

If the answers point both ways, offer both, as 8 of the 13 plans did, and put the method most customers will use first on the sign in screen.

How it works on OneCraft

A OneCraft site with visitor accounts uses email and password through Supabase Auth with a password reset, and Google sign in through OneCraft’s broker, which works on the published site and the installed app but not in the builder preview. Staff areas are separate: a site_admins table and an /admin area shown only to admins, as what an admin role is explains.

To add accounts to a site, see website with login and the website admin panel. For apps, the AI app builder gives every app an Account tab with sign in or out when the app has a database, and deep link vs universal link covers how a sign in returns to the right screen. For the features that usually come with accounts, read the website features list.