Resident Ambassador: product rebuild and domain migration

Resident Ambassador was not only a rebrand. The work combined a ground-up rebuild of the resident-facing product, a reshaped set of user journeys, and a move to a new domain. Several workstreams were already in motion when I joined, without a single technical owner across them. I took responsibility for connecting those efforts into one release and carrying the highest-risk work through to completion.

The difficult part was continuity. Existing links already lived in messages, invitations, and browser history while the destinations behind them were changing. Communications and third-party integrations also depended on the domain. A successful release needed the new experience to become canonical without turning every old entry point into a dead end.

How I approached it

Product defined the target journeys, and our three-engineer team delivered the rebuild. The work was shared; my contribution concentrated on the critical path: legacy routing and compatibility, core chat and rewards flows, payments integration, the domain and authentication transition, and email delivery. I also closed integration gaps and hardened the combined system as the pieces came together.

I started with an inventory of the user journeys that had to survive. That became a compatibility contract between the old and new experience: what should move, what should continue to resolve, and what a user should see at the end.

The contract became a shared delivery model. Product used it to confirm journey decisions; QA translated it into acceptance coverage; DevOps shaped the domain cutover; and Engineering kept product and migration changes independently verifiable. I held the boundary decisions, dependency order, and release gates across them.

Together, we:

• mapped legacy entry points to the new product journeys;
• defined a canonical routing model with explicit compatibility rules for legacy URLs;
• moved domain-dependent links, communications, and external callbacks as one dependency set;
• separated migration behavior from product changes, giving each its own verification and rollback path;
• shipped the migration as observable, independently reversible changes.

The implementation spanned application routing, communications, integrations, and release engineering. The plan kept those systems aligned around one user-level question: does every supported journey still lead somewhere coherent?

Value

The new product experience and domain shipped as one coordinated transition. Established entry points continued to lead users into valid journeys, and the teams involved had a shared model for sequencing and verifying the work.

The result was substantial change that did not ask residents to understand the migration underneath it.