Role
Solo designer & full-stack engineer — product strategy, data architecture, UI and frontend performance.
Published
2024 — 2025
- TypeScript
- React
- ClickHouse
- WebGL
- DuckDB-WASM
Impact
- 3 days → 4 hrs report turnaround
- 12k weekly active analysts
- 60fps at 2M rendered rows
Atlas started as an internal complaint: analysts spent Monday mornings waiting for a data warehouse query, then Tuesday formatting the result in a spreadsheet. The tool nobody asked for but everyone needed.
The problem
The company’s BI stack was built for dashboards — fixed questions, fixed charts. But real analysis is exploratory. Analysts wanted to slice, re-aggregate, annotate and share without filing a ticket. The warehouse was fast enough; the interface wasn’t.
What I did
I designed and built the entire product as a one-person team, reporting directly to the head of data:
- Query engine. A client-side aggregation layer on DuckDB-WASM for sub-second pivots on cached extracts, falling back to ClickHouse for full-history queries. One interaction model, two execution backends, invisible to the user.
- Rendering. A WebGL chart layer that treats rows as geometry, not DOM. Two million points render at 60fps; brushing and zooming stay smooth because nothing touches React during interaction.
- Editorial output. Every chart exports as vector SVG with typography tuned for reports — because a chart that looks bad in a PDF gets ignored.
- Collaboration. Saved views with shareable URLs turned analysis from a file-based ritual into a linkable artifact.
What changed
Weekly active analysts grew from a pilot group of 40 to 12,000 after company-wide rollout. The monthly “report week” — previously three full working days — compressed to a half-day review. The data team stopped being a bottleneck and started being a platform team.
The project also changed my own practice: it’s where I learned that performance is a design material, not an optimization pass.