Share your app without building a login system

There’s a moment every side project hits. The app works, it’s genuinely useful, and someone says the seven words that ruin your month: “can you make me an account too?”

The app took an afternoon — your agent wrote most of it. The login system is about to take three weekends. This post is about why, and about the shortcut.

What “just add login” actually means

Login sounds like one feature. It’s at least nine:

• Password storage that won’t embarrass you in a breach (hashing, salting, the right algorithm).
• Sessions or tokens, with expiry and renewal.
• A password reset flow, which means sending email, which means an email provider.
• Email verification, so accounts are real.
• An invite flow, because this app is for your five people, not the public.
• Roles — someone should be admin and someone shouldn’t.
• Revocation that actually cuts access now, not at next token refresh.
• Rate limiting, so the login form isn’t a free brute-force target.
• The security bugs you shipped in all of the above and won’t find until it matters.

That’s a professional workload — for an app whose entire user base fits in a group chat. And when an AI agent writes the auth code, you inherit one more problem: you’re trusting generated security code you can’t personally review. Auth is the worst possible place for that bet.

The workarounds, and where each one leaks

The secret URL. No login, just don’t share the link. Until someone forwards it, a browser syncs it, or a crawler finds it. Fine for a meme page; not for the spreadsheet with your team’s data.

HTTP basic auth. One shared password for everyone. No names, no roles, and “revoking access” means changing the password and re-telling everyone but Carlos.

An auth service. Auth0, Clerk, Supabase Auth — real, production-grade answers. But look under any AI-coding tutorial and you’ll find the comments: people fighting redirect URLs, email-verification config, session callbacks. You’ve replaced writing auth with configuring auth — still your project’s hardest part, still not your app.

The platform answer: apps born private

On Alora, auth isn’t something you add to the app — it’s something the platform puts in front of the app. Every project is private from its first deploy:

• A visitor hits myapp.alora.page and gets a login screen — run by the platform, not by your code.
• You (or your agent) invite people by email with a role: alora share myapp ana@example.com. They sign in free, no password of yours to manage.
• Inside, your app receives the identity as trusted headers, already verified:

const email = req.headers['x-alora-user-email'];  // who this is
const role  = req.headers['x-alora-user-role'];   // admin | user | viewer

• That’s the entire integration. Two lines of reading, zero lines of auth.
• Revoke someone and their access dies on the next request — membership is re-checked every time, not cached in a token.
• Want the world in? Flip the project to public. Want it pro? Same login works on your own domain.

The nine-item list from above still exists — hashing, sessions, resets, rate limits — it’s just Alora’s job now, once, for every app on the platform, instead of yours per project.

The honest boundary

Platform login is built for the apps agents actually produce: team tools, dashboards, trackers, client demos — groups you invite. If you’re building a consumer product where strangers sign themselves up, you’ll eventually want in-app accounts (make the project public and bring your own auth; nothing stops you). But that’s a great problem to have later — and a terrible one to pre-build three weekends for.

The account is free, $0.50 of credit covers your first deploys, and “share it with my team” is a sentence your agent already understands.