MarketsGrid: market data,
with its sources showing.
MarketsGrid is a web platform covering gold, silver, platinum, energy, currencies, Treasury yields and inflation, with long-run history, comparison tools and calculators. BBR designed and built it as its own product.
- Product
- Market data and tools platform, BBR’s own product
- Live at
- marketsgrid.com
- Front end
- Next.js (App Router), React, TypeScript, Tailwind CSS
- Data layer
- PostgreSQL with Drizzle ORM, caching layer, scheduled jobs
- Coverage
- Precious metals, energy, FX, Treasury yields, inflation
- Quality
- Automated test suites for the financial maths, validation rules and every data adapter
Free market data is easy to find and hard to trust.
Anyone can show a gold price on a web page. The difficult questions are where the number came from, whether the site is allowed to republish it, how old it is, and what happens when the source is wrong or offline.
During research it became clear that redistributable daily prices for precious metals are not freely available from official sources; that data is licensed. Many sites ignore this. We decided the product would be built on sources it is entitled to use, and would say so on the page: every figure carries a status that tells the reader whether it is official, delayed, or an indicative cross-check.
That decision cost features in the short term and shaped the whole architecture.
Adapters in, one canonical history out.
Provider adapters
Each external source, such as a central bank, a statistics office or a licensed price feed, is wrapped in its own adapter with a common interface. Adding a source means writing one adapter and registering it. Sources that require a commercial key are present but dormant until a key is configured, so the same codebase runs with free sources only or with licensed feeds.
Ingestion and validation
Incoming values are normalised to common units and currencies, validated against sanity rules, and stored with their source and timestamp. Where several sources report the same instrument, a consensus step compares them and flags disagreement instead of silently picking one.
Canonical history
Long-run series are assembled from the validated observations: daily FX reference rates back to 1999, Treasury yields back to 1990, and monthly metals prices back to 1960. Pages, charts and calculators all read from this one history, so a number on a chart always matches the number in a table.
Scheduled jobs without extra infrastructure
Collection runs on a cron-style scheduler that takes a lease in the database before each job, so two processes never collect the same data at once. This avoided a separate queue service while keeping the option to move jobs to a dedicated worker later.
Financial maths as a tested library
Unit and purity conversion, returns, annualised growth, volatility, drawdowns and inflation adjustment live in a pure domain layer that uses decimal arithmetic and has no knowledge of the web framework. It is covered by automated tests, because a calculator that is wrong by a rounding error is wrong.
Public pages built for search
Instrument, history, comparison and calculator pages are server-rendered and registered in a single SEO registry that controls which URLs exist, their metadata and the sitemap. Nothing becomes indexable by accident.
What we chose not to do.
- No invented “live” prices. Where only a delayed or monthly official figure exists, that is what the page shows, with its date.
- A monolith, deliberately. One Next.js application with a clear internal separation between providers, ingestion, domain logic and pages. It deploys as a single unit and can be split later if load ever justifies it.
- An embedded database for local development. Developers run the whole platform with no Docker, database server or cache installed; production uses PostgreSQL. The same schema and migrations serve both.
- Local-first personal features. Watchlists and saved holdings are kept in the visitor’s browser, which removed the need for public user accounts in the first release.
Relevance to client work.
Most business software has the same shape as this platform: data arrives from systems you do not control, has to be checked, stored once, and presented quickly to people who will make decisions with it.
- The adapter pattern is how we approach API and system integration in general.
- The validation and single-history approach applies to any dashboard, reporting tool or SaaS product where numbers must agree everywhere they appear.
- The stack is the one we recommend for most web applications: Next.js, Node.js, TypeScript and PostgreSQL.
We do not publish traffic or revenue figures for our products. The platform is live and you are welcome to look at it.
Planning a data-heavy product?
Let’s talk architecture.
Ingestion pipelines, validation, scheduled jobs and fast public pages are problems we have worked through on our own platform. Tell us what yours needs to do.
Discuss your project ↗