Back

Detail Pages

Austin Spaeth

Detail Pages Platform: Powering 90% of Traffic and Revenue

Highlights: Proposed and led a full rebuild after a year long stalled project; launched in 2 months, powering 90% of site traffic.

2023 / Senior Staff Engineer / proposed alternative platform after prior failure, assembled and led cross functional team, acted as product and engineering lead
Realtor.com
React
TypeScript
Platform
0→1 Delivery
Turnaround
Leadership

TLDR: After a year long failed rebuild effort, I proposed and led a new platform built from my successful off market detail page app foundation. In two months, we replaced Realtor.com’s most critical experience, powering 90% of traffic and revenue, with a modern, high-performance architecture that enabled faster iteration, lower costs, and long term scalability.


1. Context & Stakes

When I joined Realtor.com, the company was still serving its off market detail pages from a decade old Ruby on Rails application. It was slow, brittle, and nearly impossible to iterate on, even small changes took weeks to deploy and often introduced regressions. This technical debt wasn’t just slowing engineers; it was blocking product growth and revenue velocity.

Soon after joining, I was asked to lead a small team of offshore contractors to rebuild the off-market detail page experience. I architected and built it from scratch as PDP, a modern React-based proof of what a scalable detail page could be. The project was a clear success, outperforming the legacy stack across every key metric.

About a year later, another team began work on a full rebuild of the for sale detail page, one of Realtor.com’s most critical experiences. After nearly a year, the project stalled without delivering a viable product. Recognizing that the architecture I’d built for PDP could serve as a foundation for all detail pages, I proposed evolving it into a unified Detail Pages Platform capable of powering every vertical. Leadership greenlit the plan, and I was given the opportunity to make it happen.


2. Problem → Insight

Most legacy rebuilds fail because they chase feature parity instead of designing for iteration velocity. Realtor.com didn’t need a new page, it needed a platform that made future pages easier to ship.

One of the main issues I observed was that each vertical team had been layering their own if/else logic to handle unique requirements. Over time, this pattern created sprawling, fragile stacks that no one wanted to touch. We needed a model that let teams extend and customize safely, without polluting shared code or risking regressions.

Another recurring problem: front end projects were often treated as one off apps, not platforms. That fragmentation made consistency, testing, and maintenance far harder than it should be.

Key insight: Don’t give teams the option to write messy logic in core layouts and components, it guarantees another rewrite in 3-5 years. Instead, design a framework that makes the right path the easy path by abstracting customization cleanly, so the platform stays scalable and maintainable for years to come.

To make that possible, I established clear ownership boundaries, standardized data contracts, and a new "Flavor System" that allows usage of base components with custom override logic and UI per page type.


3. Approach & Architecture

  • Shared foundation, independent experiences: Each vertical (for sale, off market, rentals, etc.) runs atop the same framework with clearly scoped ownership. Components are shared through a common library, with an override layer that allows custom UI or logic without risking regressions in other products.
  • SSR first performance: Server rendered React ensures SEO and instant first paint; client side hydration handles interactivity and personalization.
  • Type safe contracts: End to end TypeScript across front end and API boundaries to enable confident refactoring and enforce data consistency.
  • Experimentation built in: Native Optimizely integration enables A/B tests, rollouts, and product experiments without redeploys.
  • Performance as a feature: Strict LCP/INP/TTFB budgets and automated build time metric gates enforced speed as a release criterion, not an afterthought.

4. Execution

  • Assembled and led a hand picked team of six engineers through the rebuild, from requirements to launch.
  • The initiative was entirely engineering driven. I acted as both PM and tech lead, managing stakeholders, defining scope, and contributing significant portions of the codebase.
  • Defined the migration strategy, rolling out progressively by geography and user cohort to minimize risk and gather performance insights early.
  • Architected and implemented the core systems, including the Flavor System and other foundational patterns that enabled scalable customization.
  • Adopted an intense one week sprint cadence with crystal clear objectives and deliverables to maintain alignment and momentum throughout the project.

5. Performance & Impact

The platform's performance gains were immediate and sustained post launch, driving both faster page loads and faster iteration velocity across teams.

MetricLegacyNew PlatformΔ
Largest Contentful Paint (LCP)3.2 s1.2 s−66%
Interaction to Next Paint (INP)~300 ms120 ms−60%
First Byte Time (TTFB)1.6 s900 ms−44%
Page Weight2.9 MB1.2 MB−59%
VariationsMultiple codebasesUnified monorepo
Number of experiments and releases a week~13-5+300%

The rebuild didn't just improve speed, it changed how fast the company could move. Product teams went from shipping once a week to iterating daily, with performance, reliability, and developer confidence all surging.


6. Leadership & Collaboration

  • Led from the front,set ambitious deadlines and stayed in the trenches with my team, coding alongside them to hit every milestone.
  • Defined the architecture and coding standards later adopted across the entire Consumer Engineering organization.
  • Mentored engineers on both technical and leadership growth, several later promoted to Staff and lead roles.
  • Partnered cross functionally with SEO, analytics, product, and design to ensure migration continuity, business alignment, and consistent user experience.
  • Built a culture of excellence, where great site performance and high performance engineering became core to how teams operated.

7. Risks & Mitigations

RiskMitigation
SEO regression during migrationHeld weekly SEO syncs and ran diff audits to ensure new pages maintained identical metadata, structure, and crawlability.
Feature parity delaysDefined a tightly scoped MVP for launch. New experiments running on legacy pages were tracked in a post MVP backlog to prevent scope creep while maintaining delivery speed.
Performance driftImplemented automated Lighthouse checks at build time and runtime monitoring alerts to ensure sustained page performance.

8. Aftermath & Lessons

The Detail Pages Platform became the blueprint for how projects should be built at Realtor.com. Today, it houses over 6 detail pages (all owned by different teams), and still has stayed easy to maintain and unlocking teams for rapid deployments without blocking each other.

It demonstrated how replatforming can drive business acceleration, not just technical hygiene.

What I’d Do Next

  • Our data has high latency (over 800ms), which hurts our performance for SSR. Am working on a project to adopt a new rendering strategy that helps us optimize for our constraints, offering a worldclass experience for our users.
  • Move away from Styled Components to a build time CSS framework like Vanilla Extract.
  • Reduce our JavaScript footprint considerably.

9. Credits

Engineering: Jay Ellul, Kevin Beaudoin, Andy Wu, Victor Cho, Youzhi Tian, Meghana Sampelli, and our leader Francisco Ovalle-Martinez

Special thanks to the SEO, Product, and Design teams for partnership through the migration.


“This project reset the bar for what ‘replatforming’ means, not just rebuilding, but enabling faster innovation across every surface.”

Signature Projects & Case Studies

Other Projects & Explorations