Multi-Exchange Crypto Tracking Platform — One screen that could have cost the entire active user base

The Problem

A technically sound migration with an unconsidered user-facing consequence

The platform's authentication infrastructure was due for a comprehensive security hardening cycle. The authentication database was running on a version that no longer received the most current security patch coverage. The internal services and APIs with database-level permissions lacked a clearly structured access record, making it difficult to audit exactly what had access and under what conditions. Password requirements for existing accounts were below the standard the team wanted to enforce going forward, and a significant share of the registered user base consisted of accounts with no login activity over several years. Engineering identified that addressing all of these concerns in a single migration was more efficient than treating each one independently, and scoped the initiative accordingly.

The migration was categorized as a self-contained backend task. The proposed implementation required all existing users to re-register on their next login. Each user would confirm their email address, create a new account entry in the upgraded database, and set a password meeting the updated policy. Engineering scoped this without routing the initiative through the product team, with the reasoning that the implementation was a purely technical operation with no design surface.

Database version upgrade and security framework hardening

Migrating to the current major release brought the authentication layer under active patch coverage and an updated security framework. The transition also established an explicit, auditable record of which internal services and APIs held database permissions, replacing an access structure that had expanded over time without a clearly defined governance model.

Verified email addresses, stronger passwords, and dormant account pruning

Re-registration enforced an updated password policy across every migrating account and linked each account to a confirmed, reachable email address. Accounts with multi-year inactivity would never trigger the migration flow, removing them passively from the active database and producing a cleaner, verified user dataset.

Full data continuity with no manual operations and minimal support volume

Every active user's profile data, including API connections, configurations, and subscription state, needed to carry across to the new database without manual export, import, or reconciliation work. The implementation was designed to minimize edge cases and avoid generating significant support load, with the expectation that only a narrow set of situations would require direct support handling.

No implementation is purely technical to the user who encounters its output. Product and design scope begins where the user experience does.

Product Intervention

Taking ownership of the product scope before engineering began development

During a sprint planning review, this initiative surfaced as an upcoming backend task ready to move into development. Reviewing the engineering specification in detail, the user-facing dimension of a full re-registration requirement had not been evaluated as part of the scoping process. Users would land on a screen asking them to create a new account. Their data would be fully intact on the other side. The screen, however, would not communicate that, and the inference a user draws from an unexpected re-registration prompt on a crypto platform is not that a routine upgrade is underway. It reads as a security incident, a hijacked account, or a phishing attempt. The result is support escalations from users who believe something happened to their account, social media responses treating it as a platform compromise, and a share of the active user base who exit the flow and do not return.

Taking ownership of the product scope before development began was the course correction this initiative needed. I led a working session with the product team to map the full technical picture from the engineering specification, examining what the migration required at the authentication layer, what event triggered a new database entry, what data had to carry across, and where in the authentication flow the product team had room to influence the user experience. Engineering's three objectives were not in question. The session was structured to determine whether those objectives could be met through a user experience that did not read as account replacement.

Solution Design

A migration the user experiences as a security update

Before any screens were designed, the product team examined the problem from the user's cognitive vantage point at each step in the authentication flow. What does the user see on their next login? What do they infer before reading any copy? What framing registers as a routine security step rather than an account-level event? The key finding from that analysis was that the migration did not need to be surfaced as a migration at all. If a user had already authenticated successfully with valid credentials, the required action was a verification step that coincided with login, not a separate account creation event. Reframing the flow around that verification context changed everything the user would infer from the screen without changing anything the engineering implementation required. The login screen remained unchanged. Users authenticated as normal. Those already in the new database continued without interruption. For users not yet migrated, the authentication flow continued into a purpose-built screen that framed the step as a security update.

The Original Proposal

Re-registration as the migration path

Users are presented with a prompt to create a new account. For users with API connections, alert configurations, and active subscriptions in their profile, the framing reads as account loss even when it is not. In a crypto product category, it reads as a security incident. The result is support escalations, social media responses, and churn from users who exit the flow.

The Implemented Solution

Security update framing on the existing login flow

Users land on the familiar login screen and authenticate as normal. Those not yet migrated see a single prompt asking them to verify their email and set a new password to continue. A new database entry is created at that point, the migration completes in the background, and the user continues directly into their full account.

The design satisfied all three engineering objectives without surfacing the migration as an account replacement event. The login event as migration trigger meant dormant accounts were never migrated, removing them passively from the active database without an explicit cleanup operation. Email confirmation at the authentication point addressed the access governance objective by verifying ownership across every migrating account, identifying profiles that had been shared or accessed through compromised credentials and reassigning them to their confirmed owners. The updated password policy applied to every migrating account within the same authentication step, with no separate enforcement phase required afterward.

The copy on the security update screen carried deliberate weight. The reassurance that user data was intact was not incidental phrasing. It addressed the specific question active users on this type of platform ask when they encounter an unexpected authentication prompt, which is not whether they can reset their password but whether their connected exchange accounts, configured watchlists, and active subscription still exist on the other side of the flow. They did. Everything stored in the user profile carried across without loss. API connection configurations, watchlist setups, alert definitions, chart preferences, and subscription status including active paid plans were migrated and linked to the new database entries. Users who completed the security update screen landed directly in their full account, intact and unchanged, with no reconfiguration required.

Screenshot of the security update screen showing email verification and password reset with clear messaging that user data remains intact — Security update screen representation framing the migration as a routine protection step with explicit reassurance about data continuity.

Outcome

Scope of work delivered

The migration completed across the active user base with full data continuity. Dormant accounts were passively removed through the trigger-on-login model. Shared and previously compromised credentials were identified through email confirmation, with ownership reassigned to verified account holders. The platform moved to the upgraded database version with defined access controls and active maintenance coverage. A small volume of support contacts were generated by users who had lost access to their original email address, handled as expected edge-case volume by the support team. The migration executed with no user-visible disruption beyond the single security update screen.

Key Observations

Three conclusions from this initiative

The boundary between a backend task and a product task is drawn at the user's experience of it

Infrastructure upgrades and database migrations are routinely scoped as backend work with no product surface. That categorization holds when the implementation genuinely has no user-facing component. It does not hold when the implementation requires users to take any action, encounter an unexpected screen, or change their behavior in any way. The engineering proposal here was technically sound and addressed every migration objective. The gap was the absence of a product perspective during scoping, and it would have shipped directly to users if the initiative had not been surfaced during planning before development began. Technical decisions made without product input and product decisions made without technical grounding converge on the same outcome, a solution that works at the system level and creates a problem at the user level. The place to catch that divergence is the scoping phase, not the launch retrospective.

How a mandatory user action is framed determines whether it registers as routine or alarming

Re-registration and a security update prompt can describe the same technical event. What separates them is what the user infers at the moment they encounter it. Re-registration implies the prior account no longer exists. A security update implies the account is being protected. In a product category where users are attuned to security threats, the difference between those two framings is not a copy preference. It is a retention decision. Screen sequencing, framing, and the presence of a clear reassurance message are product decisions with measurable consequences, and they apply with equal force when the underlying technical action is mandatory and identical for every user.

Leadership is the mechanism for catching what the process was not designed to see

The re-registration proposal had stakeholder alignment before the product team had reviewed it. The timeline was set, the scope was defined, and the initiative had momentum. The process that produced the proposal was not flawed by intent. Infrastructure work scoped as a backend task does not route through a product review by default, and that categorization is not inherently wrong. It becomes a gap when the task carries user-facing implications that the categorization placed outside the review boundary. That gap does not announce itself. The initiative looked complete, and within the process it had gone through, it was. The executive leadership function in that situation is not to assign fault but to recognize that the right process was applied to the wrong kind of task, surface the problem while the scope can still change, and take ownership of the correction. Organizations that rely on execution processes alone to catch these situations will consistently miss the ones the process was not built to see. Some processes are not broken. They are simply scoped for a different problem, and leadership is the mechanism for finding the cases they miss.