Womp 3D

Building the frontend systems behind a browser-based 3D platform as it scaled to 150,000 users.

I was one of the founding engineers at Womp. I built the component architecture, the Web Workers layer that kept the UI alive during heavy graphics operations, and watched the product grow from zero to 150,000 users.

Try Womp

"Chanakya has a rare ability to move fast across the full stack — frontend, infra, and everything in between. One of the most driven engineers I've worked with."

Gabriela TruebaCEO · Womp

600k+ users

Registered creators, from first-timers to pros.

150k+ projects

Community projects shared publicly on Womp.

Learnings

Three things building at Womp taught me that I didn't expect to learn.

Scale reveals everything

Scale isn't just a load problem — it's a design problem. The assumptions baked into your data model, your WebSocket strategy, your component architecture — all of them get stress-tested when real users show up in volume. Most of the hardest problems I solved at Womp were invisible until the product hit a certain size.

The browser is not a safe environment

I learned to treat cleanup as a first-class concern, not an afterthought. Every listener added needs a corresponding removal. Every session should end as clean as it started. In a 3D creative tool where users work for hours at a time, small leaks compound into real degradation. The discipline of writing cleanup code from the start — rather than fixing it after users complain — is one I carry into every project.

Long sessions are a different problem

A user working for three hours in a browser accumulates state, assets, and memory in ways a news article never does. Optimizing for fast first loads is necessary but not sufficient — you also have to optimize for what the product feels like an hour in, two hours in. That means thinking about session longevity as its own performance dimension with its own set of tools: lazy asset unloading, bounded caches, and explicit memory management.