A platform with live market data, on one design language

What it is

A single platform carrying a set of genuinely different products, AI tools, live market feeds, trading interfaces, analysis dashboards and browser games, under one design language, with a 3D-rendered front end.

The hard part is not the features

Anyone can add pages. The difficulty in something this size is that every addition is a chance for it to become incoherent, a different button style here, a slightly different navigation there, until it stops feeling like one product.

The discipline that prevents it is boring: one set of design tokens, one component vocabulary, and a rule that a new section uses the existing pieces or the existing pieces get extended. It is the same discipline that makes a ten-page business site feel considered rather than assembled.

Live data changes the engineering

A brochure site can be generated once and served from a cache forever. As soon as a page shows numbers that move, you inherit a set of problems that do not exist otherwise: what the page shows while the data is loading, what it shows when the upstream source is down, how often it is allowed to ask, and what stops a slow third party making your own site feel broken.

Getting this wrong is why some data-driven sites feel sluggish and unreliable. The fix is mostly about failing gracefully, showing the last known value with an honest timestamp beats showing a spinner forever, and both beat showing nothing.

What something this size costs to run

Large platforms have a running cost that brochure sites do not, and it is worth seeing the shape of it before you commission one.

There is hosting, which scales with traffic. There are the third-party data sources, which usually charge per request and are the line that surprises people. There is monitoring, because something this size fails in parts rather than all at once and you need to know which part. And there is the ongoing maintenance of dependencies, which is unglamorous and non-optional, an unpatched platform is a security incident waiting for a quiet week.

We mention it here because the honest version of a platform quote includes year two. A build price with no running estimate attached is an incomplete quote, wherever you get it from.

Why we still build it as pages, not one big app

A platform this size is often built as a single JavaScript application that renders everything in the browser. We deliberately did not do that for the public surfaces, and the reason is commercial rather than technical.

A page that renders in the browser arrives as an empty shell and fills itself in afterwards. That costs you on the first paint, it makes the experience worse on a slow phone, and it historically made life harder for anything trying to read the page, search crawlers included. The interactive parts genuinely need it and get it; the pages that need to be found and read fast do not, and do not get it.

The general rule we apply: use the heavier tool where the interaction demands it, and not one page further. Most sites that feel slow are paying the cost of that tool on pages that never needed it.

Why this matters to a smaller project

Most businesses do not need anything at this scale, and we would not sell it to them. It is relevant for one reason: the things we do on a £750 site, the speed budget, the design system, the way failures are handled, are the same habits, applied to a smaller surface. You are buying the practice, not the size.

Related case studies