Footfall
Product analytics for app teams, priced in rupees
Footfall is a sample brief. We imagined a small Bengaluru startup selling product analytics to Indian app teams, and asked what its product should feel like to use. The startup is imaginary. The product isn't: we designed and engineered it, and you can explore the live build below.
A sample brief, a real product. We wrote this brief ourselves. The business is imaginary; the product is not: we designed and engineered it, and you can use it above. We publish results only for work a client has let us verify, so this page shows none.
The brief
We imagined a young analytics company in Bengaluru whose customers are app teams: a fintech with an iOS app, a D2C brand with a website, a SaaS with a Node backend. Its promise is honest numbers, fast, priced in rupees, and light enough that people who aren't analysts open it.
We took it from an empty repo to a working product: the data model, the query layer, the chart kit and the interface.
The problem
Analytics tools drown people in options. The hard part isn't drawing charts; it's deciding what not to show, and making the few things that matter feel instant when the event data is large and messy.
- Fast queries over large event tables
- Charts that stay legible when data is ugly
- Dashboards a beginner can build alone
- A visual language that reads as trustworthy
The approach
We designed the information architecture first, then built one dashboard all the way down to the data before repeating the pattern across funnels, cohorts, segments, alerts and scheduled reports.
What would change for a team like this: Monday's numbers stop being a spreadsheet someone assembles and become a page everyone already has open.
- Typed query layer with aggressive caching
- A restrained chart kit on a single grid
- Server-driven layouts, no bespoke pages
- Motion only where it explains a change
What shipped
- Funnel, retention cohorts and event stream views
- Segments, saved and ad hoc
- Compare to previous period
- Sortable pages with search
- CSV export and a live toggle
- Custom dashboards
- Alerts and scheduled reports
- Sources with SDK snippets
Under the surface
How it is built
Event ingestion lands in Kafka and compacts into ClickHouse for fast aggregate queries; a Next.js app on Vercel streams server-rendered dashboards, and heavy rollups run as scheduled materialised views.
- ClickHouse materialised views behind every dashboard tile
- Kafka topics per event class, replayable backfills
- Row-level security tokens minted per workspace
- Edge-cached public share links with signed URLs
Considered and turned down
TimescaleDB plus Redis was the simpler path; ClickHouse won on high-cardinality queries and cost per billion rows.
Stack
The mechanism, working
The part of Footfall that was hardest to get right, as a small model you can operate.
Pre-aggregated analytics
Raw events land in Kafka and compact into ClickHouse materialised views, so a dashboard reads a few pre-aggregated rows instead of scanning every event.