Comparison content across credit cards, banking, mortgages, insurance, loans and investing, earning its audience through search rather than through a brand visit.
Fintech · Comparison platform
NerdWallet
Personalised financial product comparison for millions of monthly users.
- Product
- NerdWallet — personal finance comparison and advice
- Role
- Frontend engineer, contract
- Scope
- Next.js server rendering, comparison surfaces, rate data integration

The tension
The page has to be indexable and the numbers on it have to be current.
Rates move faster than a build. A statically generated page is indexable and stale; a client-rendered one is current and invisible. Neither is acceptable when the rate is the product.
The page a search engine indexes being the same page a visitor reads, with the same numbers on it.
Rate data comes from hundreds of institutions on their own schedules, and a wrong number in a financial comparison is a trust failure, not a display bug.
Platform-wide, across every product category.
The product story
Editorial and data on the same page, at the same time.
The proposition
Guidance before products.
The landing view leads with the decision a visitor is trying to make rather than the catalogue of products underneath it.

Narrow first
Most of this arrives from a phone search.
Comparison tables reflow to stacked cards without dropping columns, so the same comparison is possible at any width.

The numbers
Rates are content, not decoration.
Savings, CD, money market and mortgage rates sit in the page as first-class content, fetched per request so the figure is current when it is read.

Walkthrough
The platform in motion
Recorded from the live site.
The trust test
The happy path is only half the product.
A rate feed is unavailable
Rate reads are per-institution, so one unavailable source removes its row rather than emptying the table or, worse, rendering a stale figure as current.
The visitor lands mid-funnel from search
Every comparison page is self-contained and server-rendered, so arriving directly on one is a complete experience rather than a fragment.
The client bundle never runs
The guidance and the numbers are both in the server HTML, so the page informs even when nothing interactive has loaded.
The decisions
Three moves carried the story.
Server-render the comparison surfaces
The page search engines index has to be the page with the live rate on it. That rules out both a pure static build and a client-side fetch, and leaves per-request rendering.
Treat editorial and product data as one page, two sources
The CMS owns the guidance and the rate engine owns the numbers, composed server-side, so writers publish without a deploy and rates update without an edit.
Reflow tables rather than scroll them
A comparison that requires horizontal scrolling on a phone is a comparison most visitors will not complete, so the table becomes stacked cards instead of a scroll container.
What I would test next
