What if login didn’t use passwords or codes at all?
I’ve been working on an identity-first login flow.
No passwords
No codes
No recovery loops
Just:
Tap → confirm it’s you → you’re in
If you could drop this into your app tomorrow, what would stop you?
Trending on Indie Hackers
im interested... but tell me more.
The biggest blocker usually isn’t usability.
It’s trust.
“Tap and you’re in” is easy to like at the user layer.
The real friction starts one level up:
How does recovery work when the device is gone?
How does admin access work across teams?
How does security explain this to compliance?
How does the buyer defend replacing something familiar?
That’s usually where identity products get slowed down.
The UX is the easy sell.
The trust model is the real product.
Xevoa.com would carry this much better if this moves from clever login UX into serious identity infrastructure.
That framing actually clicked — treating recovery as the product instead of a fallback changes how the whole thing reads.
It also makes the trust model feel a lot more concrete instead of abstract.
Do you think positioning it that way is enough to overcome the initial hesitation, or does it still need something more visible in the first interaction?
That makes a lot of sense — especially the difference between “recovery works” and “fails safely.”
The idea of a safe window + limited access before full restore actually lines up with what I was thinking around identity confidence building over time.
Would you expect that control (like pausing or visibility) to be more system-driven, or something admins actively manage?
Exactly.
That’s why the recovery model has to be the product, not a fallback feature.
If buyers read it as:
“passwordless login with recovery”
it feels clever but risky.
If they read it as:
“identity recovery with admin-controlled trust rebuilding”
it feels enterprise-safe.
Same core system.
Completely different buyer confidence.
That’s also where the name starts to matter.
If the product moves into serious identity infrastructure, the brand has to carry trust before anyone even studies the recovery flow.
That’s exactly the line I’m trying to cross — not just a smoother login, but something that actually holds up under recovery and control.
On recovery specifically — would it feel more “enterprise-safe” if it was time-based and identity confidence builds over multiple steps instead of a single reset?
Or is there something else that usually breaks trust there?
The single-step reset is where trust usually breaks.
Enterprise-safe recovery needs visible control:
admins can see or pause it
trust builds over steps
access can be limited before it’s fully restored
there’s a safe window before anything becomes final
That’s the difference between “recovery works” and “recovery fails safely.”
You called out recovery, admin, and trust — that’s exactly the layer I’m trying to figure out before anything gets built.
What would you need to see to actually believe this works?
The trust model, mostly.
The UX is easy to understand.
What decides adoption is whether the fallback paths feel enterprise-safe.
I’d need to believe three things immediately:
recovery does not become a support nightmare
admins keep control when access changes hands
security can explain the trust model without inventing policy around it
That’s usually the line between “clever login UX” and real identity infrastructure.
In a real system, would you trust this over a traditional reset flow?
That point about recovery being the product really clicked.
I’m shaping this as identity recovery with staged access instead of instant resets.
Where do you think this breaks in practice?
It breaks when the recovery model is technically strong but hard to explain.
That’s the real enterprise risk.
If security or admins need five minutes to understand why staged access is safer than reset, adoption slows.
So I’d simplify the product around one clear idea:
identity recovery that fails safely
That frame makes the whole system easier to trust.
Then the name matters because this cannot sound like a login shortcut.
If the product is serious identity infrastructure, the brand has to feel like control, recovery, and trust from the first touch.
That makes sense — the system isn’t the risk, it’s how fast someone can understand it.
“Identity recovery that fails safely” actually makes it click immediately.
Do you think that alone is enough for adoption, or does the first interaction still need to reinforce it visually?
The visual layer helps, but it won’t fix the bigger issue if the brand still reads like a login shortcut.
For this to be taken seriously, it has to feel like identity infrastructure from the first touch.
That’s why I mentioned Xevoa.com.
It gives you a cleaner enterprise frame:
controlled access
safe recovery
trust rebuilding
serious identity layer
If you’re serious about moving this beyond a clever UX concept, Xevoa is the direction I’d test.
If not, I’d keep the current name and focus only on product validation for now.