Outcome
A new dashboard stopped being an engineering task. It became clicks. Anyone can choose what they want to see and what they don't — arrange it, bind it, and it's there. No waiting on a build cycle, no timeline, no ticket.
The shift in what the product asks of the user is worth stating plainly.
**Before**, whether you found it useful, whether it mattered to your team,
whether it was something you'd want to share with another admin — none of that
was considered. The message was *this is the information, this is the order,
look at it.* **After**, there's real control over what each admin sees, over
the visibility of data according to that admin's area of administration, and
over which data is most valuable to which administrator so that it appears
first. And they can adjust it themselves. What used to be a single fixed
arrangement became a screen that reflects the person looking at it.
---
## The map: from 4,000 points to 100,000
This is the piece I'm most attached to, because the answer wasn't the one I
started with — and the map only became fast once I accepted I'd found **two**
bottlenecks, not one.
### What was actually broken
The map had a hard ceiling at roughly **4,000 points**, and past it the tab
died. Two separate causes, sitting on top of each other:
**On the React side**, every point rendered its full detail component. Four
thousand points meant roughly four thousand detail `div`s mounted at once. That
filled memory, and then it crashed.
**On the map side**, every point was drawn as its own marker. There was no
clustering at all, and no separation of points by zoom scale — so a sudden zoom
out, with the whole country in frame, still meant every single marker being
drawn.
Neither layer had any notion that the user can only actually look at a small
part of this at a time.
### Why it became urgent
For a long time this didn't hurt, because most customers weren't using the
feature at scale. Then **Uber and Tata wanted to use it** — and the 4,000-point
ceiling went from a known rough edge to a blocker in front of two of our largest
accounts. It had to be fixed, quickly. That's when I picked it up.
### The wrong turn
**First attempt: virtualization.** I started with the React side, because that
was the crash. Only the components inside the visual window get rendered; as
the user moves across the map, components outside the visible window are never
created.
It worked — for the crash. The page **stopped crashing** and got faster.
But the map still felt wrong. **Zooming in and out was still janky.** Move the
mouse and you could physically feel the drag. The page existed now, but it
wasn't usable.
### The dig
This is the part worth writing down. It would have been easy to conclude that
virtualization was the answer and that what remained was just "the map being
slow." Instead I went deeper — and found the two problems were sitting on top of
each other. Virtualization was *a* bottleneck, not *the* bottleneck. Neither fix
alone was going to make this fast, which is exactly why the first improvement
felt like progress and still felt broken.
The test that proved it: **when I stopped passing points to the map, the drag
disappeared.** That located the second bottleneck precisely. It wasn't React any
more — it was the sheer number of markers I was handing to the map itself.
### The fix: clustering by zoom level
If the map can't take 100,000 markers, then the map should never be given
100,000 markers. It should be given whatever is meaningful **at the current zoom
level** — because at most zoom levels, individual points aren't even legible.
So I built a zoom-based cluster hierarchy:
| Zoom level | What the map is handed |
| --- | --- |
| All the way out (world in frame) | A single roll-up — *India, 2,000 points* |
| One level in | **State-level** clusters |
| Further in | **District-level** clusters |
| Close in | **Individual points per city** — how many, and exactly where |
At every zoom level, the map is handed a small number of things to draw. The
100,000 points still exist in the data — they're just never all on screen at
once, because they never needed to be.
Alongside this came **layering**: separating individual points, clusters and
sites into their own layers rather than throwing everything into one
undifferentiated pile of markers. That separation is what makes the zoom rules
above expressible at all — each layer can appear, disappear and update on its
own terms.
### Debouncing the cluster computation
Building clusters is real computation, and zooming is a continuous gesture. The
naive version recalculates on **every frame** of a zoom — which just moves the
cost from the map's rendering into my own JavaScript.
So I debounced it: the cluster computation runs based on how much zooming has
actually happened in a given interval, after the gesture settles rather than
during every step of it. The user is mid-zoom; they don't need a recomputed
cluster set at each intermediate level, they need one for where they land.
### Why clustering happened on the frontend
The backend was sending all the data as-is, and the backend team was fully
packed at that point — there was no room to change what was being sent. So the
clustering was done entirely on the frontend. That was a constraint, not a
preference, but it shaped the solution: everything above happens client-side, on
data that arrives raw.
Outcome
Before: the page crashed outright past a few thousand points, and even when it survived, the drag was constant. After: it became a completely ordinary page — fast, and smooth to zoom exactly like any other map service. The ceiling went from 4,000 points to 100,000, and the experience at 100,000 is the one you'd expect from a map, not from a stress test.
> The lesson wasn't clustering or virtualization. It was that **the first fix
> working is not evidence that the first fix was the whole answer.**
> Virtualization stopped the crash and improved the page, and that success is
> exactly what would have made most people stop. The map only got fast because I
> kept going after the numbers had already improved.
---
## What I take away from this
### The through-line
If I had to name the one thing I'm good at, it's **finding the actual problem**.
Someone comes to me and says "this page isn't working." That sentence contains
no information. My job starts there — working out *why* it isn't working,
whether that's the performance of a page or the performance of a map.
Virtualization, layering, clustering: those were the answers, but the value
wasn't in knowing those techniques. It was in isolating the exact problem each
one was the answer to — and, in the map's case, in not stopping when the first
answer already looked like a win.
The other half is that I can build a project from the base — given a clear
requirement and a clear picture of how far it has to go — and build it to be
scalable. On the frontend, scalable means something specific to me:
- **performance is good**
- **good practices are followed**
- **state management is correct**
- **components are structured in a correct, deliberate way**
Those four aren't a checklist you apply at the end. They're the decisions that
determine whether the thing survives its second year.
### What a year and a half taught me
Most of what I learned came from working inside a **large codebase with a lot of
dependencies**, where different teams work on different products and your change
is never only your change.
What I learned was a way of approaching work that arrives badly defined. A weak,
loosely-specified problem lands on your desk, and the job is to give it
structure:
1. **Do a thorough architecture analysis of the current code** — understand what
exists before proposing to change it.
2. **Propose a solution on the basis of that analysis**, not on the basis of
what you'd do on a blank page.
3. **Implement it in phases.**
4. **Test it, and find the bugs.**
5. **Fix them.**
6. **If something is wrong, turn around and make the right decision** — rather
than defending the first one because it's yours.
7. **Debug the existing problems**, so the same class of problem stops
recurring.
Point six took the longest to internalise, and the map project is a monument to
it. Being willing to say *this isn't it, go back further* is worth more than
being right the first time.
### The technical ground
Set out plainly, across these four projects:
- **Virtualization** — rendering only what's in the visual window, and not
constructing what isn't
- **Zoom-based clustering and layering** on a map, with debounced recomputation
- **Configuration-driven UI** — JSON describing position, data, appearance and
representation
- **Type-based component mapping** — turning a config entry into the right
rendered component
- **Compound / sub-component systems** — `