DeHubOpen DeHub

DeHub › Blog

Faster and Sleeker: major app upgrade reveals UI Overhaul and 200% Backend Speed Boost

By DeHub Team — 2024-10-28

DeHub Q3 2024 update: Faster and Sleeker: UI Overhaul and 200% Backend Speed Boost

In Q3 2024 we overhauled the user interface and improved backend speed by 200%.

Why they shipped together

Because separately they are both bad releases.

A redesign on a slow backend is a slower app that looks different, and users experience it as a downgrade no matter how good the design is — the visual change draws attention to every wait. A backend improvement with no visible change is invisible: users do not notice three times faster if the thing they are waiting for looks exactly the same.

Together they are a single perceptible improvement. Everything looks different and everything responds immediately, and those reinforce rather than undermine each other. That is why the same release drew 95% positive feedback.

What "200% faster" means

Three times the previous throughput, across the paths that matter — feed loads, stream starts, wallet operations, arcade launches.

The honest detail is that this was not one clever optimisation. It was the accumulated cost of four years of shipping, paid down. Queries written when the dataset was small and never revisited. Sequential calls that could always have been parallel. Caching applied where it was easy rather than where it helped. Every one of them was individually reasonable at the time and collectively expensive.

There is no glamorous version of this work. It is measurement, then unpicking, then measuring again.

What the overhaul actually changed

Less than a screenshot comparison suggests, and more than users could articulate.

The 50 user interviews from 2021 had produced two findings that remained true three years later: wallet setup was where people gave up, and anything requiring a mental model to understand its value was treated with suspicion. The overhaul was largely those two findings applied across the whole surface.

Fewer steps between opening the app and doing something. Clearer statements of what an action is worth before you take it. Less of the app assuming you already knew how it worked.

What it did not fix

Onboarding, entirely. It got better and it remained the most common place people stop, which is the single most persistent finding in DeHub's history.

Discovery also stayed weak, and that fed the feed revamp with audio replies and live talk spaces the following year.

Why the speed work mattered most

Because everything after it depended on the headroom. The Livepeer integration for 50,000+ concurrent viewers, the custom CDN and 99.99% uptime in Q1 2025 all arrived within two quarters, and none of them would have been survivable on the backend as it stood in mid-2024.

How the debt accumulated

Not through carelessness, which is the comforting explanation and the wrong one.

Every slow query in that codebase was written by someone competent, under a deadline, against a dataset where it performed fine. Every sequential call that should have been parallel was sequential because that was the simplest correct version at the time. None of it was a mistake when it was made.

The mistake was structural: nothing in our process ever revisited a decision after the conditions that justified it had changed. Code was reviewed when written and never again.

The fix was not better engineers. It was making performance a standing measurement rather than an incident response, so that degradation shows up as a trend rather than as a complaint.

← All DeHub blog posts · dehub.io home