Security in Your Own Hands: Profile Hub and 2FA

Two-factor authentication on a smartphone Photo: Fabian Irsara · StockSnap (CC0 1.0), via Openverse

There's a moment in every product where you notice account management has secretly turned into a patchwork. For us, it came when I wanted to explain to a user where to change their password — and realized that setting lived in a completely different place than their notifications, the subscription overview was somewhere else again, and the security features were practically undiscoverable. Each of these pages made sense on its own. Together, they didn't add up to a coherent picture.

This week is therefore about something that looks unspectacular from the outside and was a lot of cleanup work internally: we bundled account management into one place and gave users tools to take their own security into their own hands — without the detour through our support.

A Hub Instead of Scattered Pages

The new starting point is a profile hub at /profile. Instead of spreading account management across the whole product, this single page brings together eight areas: from personal master data through security and two-factor authentication to subscriptions, notifications, and organization memberships. Each area is its own tile, and each tile is a clearly scoped task.

The decision to build it as a hub rather than as one single long settings page was deliberate. An endless wall of forms would have created the same problem in new packaging — you scroll, lose track, and still find nothing. Eight tiles, on the other hand, immediately give you a mental map: you see at a glance what's available and pick exactly what you need. The hub answers the question "Where do I configure that?" before it's even asked.

Two-Factor Authentication Without a Detour

The area that carried the most work is security — and within it, two-factor authentication in particular. Until now, something like this was more of a support-ticket case for us: you wrote to us, we enabled something, it took time. That's exactly the kind of friction that leads to security features going unused. Hardly anyone activates 2FA if they first have to request it.

That's why two-factor authentication is now fully self-service. Users activate it themselves, directly in the profile hub, without any human on our side having to step in. The flow is the expected one: you set up an authenticator, verify a code once, and from then on the second factor is live. What sounds technically simple shifts responsibility to the right place — to the user, who determines their own security level instead of waiting for us to unlock it for them.

The fact that we model this through Auth0 as the identity layer helps here: the actual factor management sits with a hardened provider, and we focus on the interface and the state in our own model. The self-service nature of it isn't a side effect, it's the actual goal.

Why Self-Service Is the Guiding Principle

Behind both building blocks lies the same thought, and it matters enough to me to spell it out: security and control belong in users' own hands. Every feature that only runs through us is a feature that's slower than it needs to be, and that creates a dependency nobody wants — neither us nor the users.

Self-service doesn't mean offloading responsibility. It means building the tools so that the obvious action is also the secure one. A profile hub that makes security options visible, and a 2FA you can activate yourself in a minute, do exactly that. They turn the secure path into the convenient path.

Photo: Negative Space · StockSnap (CC0 1.0), via Openverse

The Hard Case: Leaving While a Subscription Is Active

The most interesting part of this week wasn't the 2FA, but a question that sounds harmless and isn't: what happens when someone wants to leave an organization for which a subscription is still active?

The naive answer — leave immediately, subscription gone — is wrong. The user has paid for the current period. Kicking them out immediately would mean taking away something they've already paid for. Conversely, an announced departure can't simply stay without consequence either, because then nobody would ever really leave. The real task lies between these two mistakes.

We solve this by modeling the departure not as an immediate action but as a scheduled event. The membership model got two new fields for this: LeaveScheduledAt records when a user triggered the departure, and EffectiveAt records when it actually takes effect. Between these two points in time, the membership stays active — the user keeps their access for exactly the period they've paid for.

Two Systems That Have to Stay in Sync

The core of the matter is that two truths have to line up here: the state of the membership in our database and the state of the subscription at Stripe. If the two drift apart, exactly what you never want happens — someone keeps paying even though they've left, or loses access they should still have.

The flow is therefore deliberately two-staged. When a departure is scheduled, we don't cancel the subscription immediately, but set it, via SetCancelAtPeriodEnd, to "ends at period end." Stripe continues the service until the paid period expires and then simply doesn't issue a new invoice. Only once that period runs out does the departure become final — and only if it was actually scheduled. That last condition sounds pedantic, but it's crucial: it prevents a period end that occurs for a completely different reason from accidentally removing someone from an organization who never wanted to leave. The transition to "departed" status happens exclusively on the basis of a previously set plan.

This is one of those places where the correct solution costs noticeably more code than the wrong one. An immediate delete would be two lines. A scheduled departure with clean subscription coupling is a state model with two timestamps, a conditional finalization step, and the discipline to never touch the Stripe state and our own state independently of each other. It's worth the effort, because real money and real trust are at stake here.

How This Feels for Users

From a bird's-eye view, this adds up to a coherent picture. The profile hub is the map through which you find everything. Self-service 2FA is the first concrete promise of that map: you determine your own security. And the scheduled departure is the same idea, applied to an uncomfortable moment — even leaving stays in the user's own hands, handled fairly and without them losing anything they've paid for.

None of this is particularly show-worthy. These aren't features you'd advertise on a homepage. But they're exactly the things that decide whether a product feels trustworthy or not — and that you're most likely to miss precisely when they're absent.