Meta Family Center
Visit LiveRole
Engineer, then tech lead & engineering point of contact
Team
rotating 2 to 5 engineers
Stack
React (Flow), Relay, GraphQL, PHP SSR, CMS, i18n
Status
Live, 64 locales
Description
Meta Bug Bounty is Meta's security research program website, where ethical hackers can report vulnerabilities across Meta products and technologies. The site provides program rules, eligible targets, reporting guidelines, and reward information to help researchers responsibly disclose bugs that could affect user safety, privacy, or platform security.

I joined Family Center as an engineer and became its tech lead and engineering point of contact. I led the migration of a 64-locale marketing site to Meta's modern infrastructure in two steps: first, the backend and rendering stack, then the UI and component library, which modernized the site onto Meta's current internal systems. I was the liaison between the engineering team and the product owners, owned scoping and rollout, conducted feasibility checks on what the team could realistically build, and still shipped features myself.
The problem
Meta was sunsetting the legacy infrastructure and moving teams onto a new backend and UI stack, so Family Center had to migrate. The site was live in 64 locales, and the backend migration had to be a hard cutover; the infra team had no way to feature-flag the switch, which made it high-risk for a site of that size.
Leading Family Center
I was the bridge between a rotating team of 2 to 5 engineers and an internal product owner team. My job was to turn what the product side wanted into work that engineers could build, and to be honest about what it would cost.
- Acted as the feasibility check on the design. When a tight deadline made an intricate design unrealistic, I weighed the build cost, chose the implementation route, and pushed back on scope rather than absorbing the overrun.
- Scoped the engineering work after the PM broke initiatives into milestones, and gave estimates calibrated to where each engineer on the rotating team actually was.
- Onboarded engineers rotating onto the project. Got them up to speed on Meta's infrastructure and tooling, why the codebase follows the patterns it does, and why we were migrating, then answered their questions on both.
- Was the on-call point for bugs during development and the migration, and for smaller issues after launch.
- Ran weekly syncs with the product owner team alongside the PM and PO, and pulled analytics data for them when they needed it to make calls.
What I built
- The SSR plus CMS integration layer, migrating ~47 pages from static generation to dynamic server-side rendering while keeping localization and campaign logic intact.
- Family Center's URI localization toolkit, which encodes the site's specific locale logic so navigation, footer, and banner links resolve to the correct locale on every page.
- A dynamic, CMS-driven sitemap system (HTML and XML) that filters published pages by locale and country.
- A CMS-driven JSON-LD structured data system and component, built for the site, generating per-page SEO structured data.
- Site analytics and event tracking, instrumented on Meta's internal telemetry platform, capture session-level and per-component click data.
- A large batch of WCAG fixes as part of a site-wide accessibility audit, such as alt text, color contrast, and semantic markup.
- End-to-end expansion into 6 new international markets: locale routing, hreflang, country selector, sitemap, and navigation.
How I approached it
The migration came in two steps. The backend and server-rendering infrastructure went first. The infra team had no way to feature-flag the switch from the old stack to the new one, so the cutover was difficult and high-risk. During the cutover, a controller setting hadn't been updated, so part of the traffic wasn't reaching the new controller, and the site went down. I diagnosed it and pushed the fix immediately, and the site was down for a few hours.
The second step was migrating the UI onto Meta's new UI infrastructure and current component library. This one I could feature-flag: content resolved from the redesigned folder first, with a fallback to the current folder, so the new UI rolled out locale by locale and degraded safely if anything was missing. It meant moving over every component we'd built and rewriting some, a lower-risk than the backend cutover, but time-consuming.
The payoff was access to Meta's modern internal tooling, the legacy stack couldn't use: a current component library, JSON-LD support, Meta's internal accessibility analytics, fuller site analytics, and the locale tooling the site needed.
Outcome
- Migrated a live 64-locale site across both the backend and UI stacks, delivered with a rotating 2 to 5 engineer team.
- ~47 pages moved to server-side rendering.
- Site serving an estimated 3 to 7M monthly active users.
- Shipped into 6 new international markets, end-to-end.
- Resolved the production out-of-memory crash in the sitemap generator.
