Caspian

Context

I joined Caspian as the second engineer three months after founding, when the backend existed and the Figma file was still aspirational. The product was a B2B analytics platform for mid-market e-commerce teams — the kind of merchants who'd outgrown their native Shopify analytics but couldn't justify a Looker implementation. My job was to build everything the user touched.

The problem

The core challenge was making firehose-volume event data readable to a non-technical operator without hiding the detail an analyst might need. Most analytics tools solve this by building two separate interfaces. We had four months of runway and two engineers.

What I built

I owned the full frontend from design system up. The hardest problem was the chart layer: 12+ chart types, consistent across dashboards, drill-downs, and exports, with acceptable render performance on datasets that could hit 100k rows in a single response.

The solution was a thin normalisation layer over Recharts that handled data transformation before it touched the component. Product could compose new views without opening a renderer. We shipped the first dashboard in six weeks. By month eight we had drill-down filtering, export to CSV, and a public-facing embed for merchants to put on their own sites.

A decision I'd revisit

We used React Context for state management. It was fine until the product grew complex enough that prop drilling was replaced by re-render debugging. I'd reach for Zustand or Jotai earlier next time — the explicit atom model makes performance problems visible before they become user-facing. That said, React Context got us to 40 customers. The perfect architecture you ship in month twelve doesn't help the customer you lose in month six.

Outcome

40 paying customers before the Series A fell through. The product was fast, honest about its scope, and the customers who used it liked it. I'm proud of what we shipped given the constraints. The shutdown was about funding environment, not product quality.