Our search and listing detail pages are Realtor.com's two most critical traffic and revenue surfaces, and both were still running on a roughly five year old Next.js 12 foundation.

Those pages had grown slow and bloated, and the sluggish performance was directly dragging on core business metrics. Benchmarked against our two largest competitors, Zillow and Homes.com, we had the slowest search page of the three. Yet performance had never been an organizational priority, and no one owned fixing it.

Prior upgrade attempts had already exposed the core problem. Incremental fixes were not removing the structural bottlenecks, and roll-forwards kept getting rolled back after performance regressions tied to abstraction and JavaScript bloat.

So the case for Oracle was never just "modernize the stack." It was to close the performance gap to competitors, move revenue-sensitive speed metrics, and build a frontend platform that is cheaper and easier to evolve.

Before writing a line of the prototype, I mapped each problem to the architectural insight it pointed toward.

This was not an assigned project. I saw the problem and the opportunity myself, and rather than wait for a mandate, I built a prototype with another developer, Victor Cho, to prove the approach out, then used the results to push leadership to invest.

That prototype was the proof that made Oracle credible. Built in under a month and brought to roughly 80% parity with production, it demonstrated that our performance theories were not hypothetical.

It also gave us a practical benchmark for the shape of the future app. The results were strong enough to change the conversation.

The prototype was not Oracle itself. It was the forcing function that proved a rebuilt search page could be materially faster, commercially interesting, and worth turning into a full platform bet.

"The prototype proved the performance theories were not hypothetical."

Oracle's core strategic choice was to rebuild the search page from the ground up rather than keep stacking patches on the old app. We delivered it with a small team of just three engineers, and the execution was deliberately staged.

• Earn trust first. Started with an IPR to build trust and shared understanding with the engineers who would have to adopt the platform, and to align on the future stack and paved paths before any code was written.
• Build fast. We set a two month delivery target. I pushed the team to lean on Claude religiously and worked with them on workflows that shipped fast without sacrificing quality: we define the structure and standards in code, then have Claude mimic them.
• Roll out incrementally. Use traffic split routing so we could compare Oracle and legacy traffic and roll back without a redeploy.

Every layer of Oracle was chosen for performance, governance, and long-term control.

A less obvious highlight is that Oracle was built to preserve room for what comes next: shared adoption across verticals, React Native or hybrid integration, and broader platform simplification across Consumer Web.

The headline is simple. Oracle was designed to win decisively on speed against the legacy search page, and to be at least competitive, and better on several metrics, than every major peer.

Oracle's business case was tied directly to page speed. Internal FY26 analysis had already shown that a 100ms TTFB improvement correlated with roughly +1.3% eCPM, and other site-speed experiments showed positive movement in page views, engagement, and lead submissions whenever pages got faster or lighter.

The honest story was mixed.

• In rollout, Oracle showed clear top-of-funnel and search engagement gains: for-sale page views per user +2.44%, search page views per user +4.30%, search map page views per user +8.41%, searches per user +12.08%, and search lead submission rate +10.17%.
• It showed downstream pressure: listing-page views per user -1.75% and listing-page lead submission rate -3.24%, though not statistically significant.
• We expected that migrating the listing detail page to Oracle next would relieve the downstream signals we saw on it after the update.

Oracle was never pitched as a dependency upgrade. I positioned it as a deliberate bet on speed, revenue, and frontend standardization, and backed it with a formal review to win alignment and resourcing.

The work was carried by a small, named team. I conceived the idea and the framework and built the prototype; my mentee Jay Ellul led and built the production platform, with leadership backing from Francisco Martinez.

We treated rollout discipline as part of the product itself. Feature flags, New Relic, Amplitude comparisons, parity tracking, and rollback readiness were all in the plan from the start.

Oracle also advanced more than page speed. It forced alignment on ad parity, design-system migration, governance, and shared engineering conventions that will outlast the search page itself.

Oracle proved that the old search-page performance ceiling was real, and that structural frontend change could move the needle in a way incremental cleanup never could.

It also reframed performance itself. What the company had treated as an engineering detail turned out to be a growth lever, lifting real engagement and lead submissions once the pages got faster.

The deeper lesson is that performance is not just Core Web Vitals or a dashboard of metrics. It is how a consumer actually experiences the page: how responsive and effortless it feels, the intangibles that numbers never fully capture.

The rollout discipline was a real win. The Oracle team found problems at 1% and 5%, corrected them, and kept moving, instead of forcing a full launch on schedule and absorbing uncontrolled damage.

Oracle was carried by a small, focused team. Special thanks to everyone who shipped it.