Saleslens is a multi-tenant analytics product I owned and shipped at Salescode.ai — a live, solution-specific dashboard sitting on top of each client's own database. It went live with five enterprise FMCG clients, including Coca-Cola.
A dashboard layer for Salescode's three products — SFA, eB2B and DMS — that reads from each client's live database and shows them their own performance. I picked it up as an early-stage initiative from a senior colleague and took it from concept to build completion: metric definitions, product design, user stories, and the build itself.
Salescode sells three things into enterprise FMCG: Sales Force Automation for the field, eB2B for retailer ordering, and a Distributor Management System for the channel. Each one produces a rich transactional trail — orders, visits, retailers, schemes, SKUs.
None of it came back to the client. There was no live, solution-specific dashboard wired to their actual database. If a brand manager wanted to know whether eB2B adoption was moving, the answer arrived as a report pulled by hand by a Salescode employee, on request, on a lag.
The initiative had been opened up by a senior colleague and then stalled — the appetite was proven, but there was no metric set, no design and no build plan. I picked it up from there and took it to completion.
Saleslens isn't a single dashboard pointed at everything. It's a multi-tenant layer that renders a different product depending on which Salescode solution the client runs:
have a click around — it’s live ✿
The cheap version of this is a single generic dashboard pointed at every database. It ships faster and means less. A DMS client and an eB2B client don't have the same questions, so each solution got its own metric set, defined on its own terms with my manager.
A dashboard that's a day stale invites the same phone call it was built to replace. We went multi-tenant against each client's live database — the harder architecture, and the reason the Coca-Cola scale problem surfaced at all.
I built the low-fidelity structure in Figma myself — what goes on screen, in what order, at what altitude — then brought in a designer for high-fidelity UX. Handing over an undefined brief spends a designer's craft on decisions that are really product decisions.
Visibility into your own data shouldn't sit behind a paywall — it's a necessity layer that makes the products underneath it defensible. Core dashboards shipped bundled with each solution; the deeper analytical features became a separately sold add-on.
Decision 01 reads as obvious and was the longest part of the work. “Show me how we're doing” is not a specification. For each solution I had to convert a vague client instinct into a metric with an unambiguous definition.
eB2B is the clearest example. Retailer counts are easy to produce and easy to misread — a retailer who installed the app once is not a retailer using it. So the eB2B set separated the funnel:
The definition I'd defend hardest is “adopted” set at three or more orders. One order is curiosity. Two can be a rep standing over someone's shoulder. Three is a habit forming. Drawing that line means the number can go down in a bad month — which is exactly what makes it worth showing a client.
I laid out every screen myself first — which metrics appear, in what hierarchy, and what a client sees in the first three seconds. Structure settled before any visual work started.
With the structure fixed, a designer took it to high fidelity. Their time went into craft and interaction rather than into resolving open product questions.
Every story carried the exact definition it implemented — including the three-orders rule — so “adopted retailers” meant one thing to me, the designer and the engineer.
I ran daily check-ins with the build team across the whole implementation, which is how the Coca-Cola performance issue got caught and turned around inside the build rather than after it.
Everything held until we pointed Saleslens at Coca-Cola. Their dataset was an order of magnitude past anything else we'd tested, and it broke the product in two ways at once.
The first was performance: load times degraded badly under that volume, on the live-database architecture we'd deliberately chosen. The second was subtler. At Coca-Cola's scale the raw figures ran to seven and eight digits, and a tile reading 1,204,839 is accurate and useless — you can't scan it, and you can't hold two of them in your head at once. We had built a data interpretation product that couldn't be interpreted.
I solved both directly: performance optimisation on the query and load path, and K/M/B rounding and formatting applied across the metric surface so magnitude reads instantly while precision stays available where it's needed.
same data — one of them you can actually scan ✿
Saleslens shipped across the SFA, eB2B and DMS solutions and went live with five enterprise clients. Core dashboards were bundled free with each solution; the advanced feature set sold as a paid add-on, making the product a revenue line rather than only a retention play.
One honest note on the outcome. This product has no single before/after metric, and inventing one would be dishonest. Before Saleslens, clients had no visibility into their own solution performance at all — the comparison isn't better versus worse, it's nothing versus something. That's what a necessity layer looks like: its value shows up in renewal conversations that run on evidence instead of assurances, and in report requests that stop landing on a human's desk.