About a year ago, our dashboards took so long to load that people stopped checking them in the morning and waited until after lunch. That's usually a clear sign something's wrong — the point where people quietly give up on a tool.

We'd grown a lot in a short window: more signups, more events flowing through the system, and a product team that wanted to ship faster than the backend could handle. The stuff that had been fine for two years started falling over, one piece at a time. Here's what broke, why, and what we did about it.

What Was Actually Broken

We'd point to three things — though honestly it took us a while to separate them, because they were all making each other worse at the same time.

The database was drowning. Telemetry was sitting in a regular relational database, which is fine until it isn't. Once event volume picked up, analytics queries slowed to the point where a "real-time" dashboard was showing you ten-minute-old data if you were lucky. Then we found out a huge chunk of that data was bot traffic anyway — fake sessions, scraper hits, junk logs, all mixed in with the real numbers. So even when a query did come back, nobody fully trusted it.

Every page was quietly hammering the database. This one's a classic. Load a list of 100 items and, instead of one query, you get 101 — one for the list, then one more for every single item's related data. It's the N+1 problem, and it's the kind of bug that doesn't show up in a code review, only in production, under load, at 2 p.m. on a Tuesday when everyone's using the app at once.

The frontend fought us on everything. We were still running old WordPress templates with iframes patched in for the parts WordPress couldn't handle. Lighthouse scores were embarrassing. And any time someone wanted to ship a small feature, they'd lose two days working around the existing mess before they could write the actual feature.

Any one of these we could have lived with. All three at once, feeding each other, is how a platform goes from "a bit slow" to "actively losing our trust."

How We Fixed It — Without a Full Rewrite

We talked briefly about starting over. Then we didn't, because a full rewrite on a live platform is how you turn one problem into six. Instead, we went at each layer separately.

Data. We moved the high-volume metrics onto ClickHouse — a columnar database built for exactly the kind of aggregation-heavy queries analytics dashboards run all day, which a standard row-based database just isn't. Instead of every service reporting data its own way, we put OpenTelemetry in front of logging so everything reports the same way, and we started filtering bot traffic out at the source rather than scrubbing it later. Query processing dropped to single-digit milliseconds — and trust in the dashboards came back with it.

API. To resolve the N+1 issue, we built our own DataLoader middleware to batch repeated queries into one. We also dropped polling in favor of websockets, since polling every few seconds is just wasteful. And we embedded Sentry so we trace problems from an alert instead of from an angry user.

Frontend. WordPress is gone. We split things into Astro for the static, content-heavy pages and Next.js for anything dynamic that needs server rendering. Old UI components were swapped for Shadcn/UI and Tailwind — which sounds like a small thing until you're the one maintaining it: less code, less weirdness, easier to change. We also added a few Flowise-powered workflows to automate some of the more repetitive internal tasks — less because it was flashy and more because it freed up actual hours.

What We Got, and What It Cost Us

Numbers, for what they're worth: 3x faster page loads. Lighthouse scores over 90. About 80% less JavaScript shipped to the browser. Analytics queries that used to run for seconds now run in milliseconds. Real-time actually means real-time now.

It wasn't free, and it wasn't fast either. We spent real time and money up front rearchitecting things properly, the team had to learn tools they weren't using six months ago, and we had to be careful with the migration order so we didn't take anything down for people actively using the platform. If you're expecting a weekend project, this isn't that.

But we did the math against what it was costing us to keep limping along, and it wasn't close.

Why Any of This Matters Beyond Engineering

None of this was really about making things fast for the sake of fast. It changed how the team works day to day. Features that used to take two weeks because the API fought back now take a few days, because the API doesn't fight back anymore. Leadership stopped second-guessing the analytics, because the analytics stopped being wrong. And a hundred milliseconds of latency sounds tiny until you look at what it costs in lost conversions — which, it turns out, is a lot.

Basically, when the platform stops being the bottleneck, the business starts moving at whatever speed its ideas deserve, instead of whatever speed the old code allowed.

Where That Leaves You

If any of this sounds like your platform, the fix probably isn't a full rewrite either. It's finding the two or three places where the architecture is actively working against you, and fixing those first.

Dealing with something similar? Talk to Endure's engineering team about your setup — we're happy to just talk it through, even before there's a project attached.

A Few Questions People Usually Ask

• What does “platform modernization” mean, really?: Upgrading the frontend, backend, and data layer of an existing system to make them faster and easier to maintain — usually in stages, instead of one giant rewrite.
• What's the N+1 problem in simple English?: Retrieving a list triggers one query per item instead of one query for the whole list. Ask for 100 things and you get 101 database calls. It's invisible until you're under real load.
• Why ClickHouse and not just a bigger Postgres instance?: Different tools for different jobs. Relational databases are built for transactions — reading and writing individual records. ClickHouse is built for aggregating huge volumes of data fast, which is what analytics actually needs.
• How long does a project like this take?: It depends on the size of the platform, but doing it in layers — data, then API, then frontend — means you can keep the lights on the whole time instead of betting everything on one risky cutover.