Relaunching the account platform

The Account Application relaunch was a three-year effort, and the biggest single project I’ve owned at Unraid. From the outside it looks like an account portal. The real work was a coordinated migration across identity, commerce, license state, entitlement checks, SSO behavior, support tooling, callback safety, and key management systems that had to keep producing correct license outcomes the whole time.

The arc, concretely: I designed the AWS Cognito user-pool architecture and migrated 70,000+ users off forum-based identity (with presignup lambdas, MFA, and drift-repair paths), then led the “account v3” rewrite — a full Nuxt application deployed to Cloudflare Workers with Drizzle ORM, queues, and Hyperdrive — which shipped in August 2025 and fully replaced the legacy account website that November.

A launch mistake here would not feel like a small bug. It would feel like a user could not sign in, could not activate a product they just paid for, could not extend a license, or could not get a support operator to understand what happened to their order. That risk framed every decision.

Why this work mattered

Account systems are not just account pages. They are where purchase confidence, activation, support, and product lifecycle meet. The Account Application sat between users trying to buy or activate Unraid, the key management systems responsible for license behavior, Stripe checkout and subscription flows, support operators trying to make sense of account state, and a pile of legacy account, order, and forum-identity infrastructure that had built up around old purchase paths.

I structured most of the work as a staged migration so critical account behavior could move forward without one high-risk cutover. Smaller changes support already understands are easier to ship than one big-bang launch nobody can roll back.

What I worked on

• A modern account dashboard for order history, license state, subscription management, and trial visibility, sitting on a production Postgres database instead of legacy key-management views.
• SSO and session behavior that made sign-in predictable across account.unraid.net, the marketing site, and product surfaces behind Cloudflare Access for controlled internal and pre-release rollout.
• Stripe and PayPal purchase and subscription flows — pricing pages, A/B-tested checkout, order confirmation driven by job queues — including a fix for the 100% Stripe coupon path that was not sending the license/activation code on completion.
• An extend-license-early flow, because the original extend button only appeared after expiration and customers were buying a second license to recover.
• Trial-to-license conversion with callback behavior into Unraid, so a user could start in the WebGUI, move through purchase, and come back with license state the product actually understood.
• Bulk and OEM activation-code handling — including redemption flows and generated PDF codes — so partner and business purchase patterns did not need a custom workflow each time.
• Guardrails on activation-code generation so purchase and fulfillment paths stayed consistent under edge cases.
• Safer callback behavior for account and Connect-server updates, shipped with a change-management plan, validation path, and clean rollback story.
• Compatibility work across the key management layer so license state, activation behavior, and support workflows stayed reliable while the account platform moved forward.
• Account-data synchronization work from Cognito into downstream platform systems, with retries and repair paths for drift.
• A multilingual application structure (SimpleLocalize-backed) so account flows could serve a broader user base instead of staying English-only.
• Admin dashboards for customer management, key recovery, and queue monitoring — plus internal MCP tooling with reversible transforms over sensitive data, so support and AI-assisted workflows never handle raw customer records.
• A sharded end-to-end test suite that provisions real Cognito users across parallel GitHub runners, because an identity platform deserves tests against the actual identity provider.
• A FeatureOS-backed checkout experience survey, so the next round of fixes came from what real users said about purchase and activation, not just internal opinion.

How I shipped it

I treated the release plan as part of the product. The questions that mattered were not just “does the page render” or “does checkout work.” Every change had to answer support readiness, rollback, validation, and customer-impact questions before it went out. Did support know what changed? Did account.unraid.net resolve correctly? Did sign-in work behind the proxy path? Did session changes create confusing loops? Did user-facing error states say something true when a license or trial could not proceed?

Working this way is what keeps platform migrations from turning into customer support incidents. The Account Application touched enough systems that every change needed a clear validation path: account creation, login, purchase, trial upgrade, license visibility, subscription visibility, support lookup, activation-code redemption, and key-management behavior.

Outcome

The Account Application now owns durable user-facing account state. Users can sign in, see purchase context, manage subscriptions, redeem activation codes, convert trials, and move through the product lifecycle without needing to know how many systems are involved. Support has one legible surface for license, order, and account history. Engineering got a staged path away from legacy account and checkout systems instead of trying to replace everything in one launch window.

Good account work should feel quiet. It should lower user anxiety, keep purchase and activation paths reliable, and make support more effective when something unusual happens. It’s also the foundation we built partner purchasing, OEM activation, and the next set of license workflows on.