Skip to content

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
NerdWallet case study cover

The tension

The page has to be indexable and the numbers on it have to be current.

What was happening

Comparison content across credit cards, banking, mortgages, insurance, loans and investing, earning its audience through search rather than through a brand visit.

What changed the brief

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.

Success looked like

The page a search engine indexes being the same page a visitor reads, with the same numbers on it.

The constraint

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.

Millionsmonthly users

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.

NerdWallet — landing view
Categories as entry points.Credit cards, insurance, mortgages, loans — each a route into a comparison surface.

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.

NerdWallet — mobile view
Tables become cards.Reflow rather than horizontal scroll, so nothing is hidden off-screen.

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.

NerdWallet — full page
Server-rendered, request-fresh.The indexable page and the read page carry the same numbers.

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

Per-request rate fetching is correct and expensive. Where a short revalidation window would be indistinguishable to a reader is worth measuring per category.