← chintan shingala / home case study 3 of 4
  CASE STUDY — CLEARGLASS

The operational bottleneck that became a revenue line.

Role
PM, Data & Automation
Company
ClearGlass — pensions cost transparency
Timeframe
2024 – 2026
Status
live — scaling after first collection cycle

The situation

ClearGlass analyses, validates and benchmarks what pension schemes pay their asset managers. LGPS fund data arrived as an operational bottleneck: deeply hierarchical structures, processed by hand, every collection cycle. The platform that came out of it wasn't on anyone's roadmap — it was hiding inside the ops queue.

note: visuals on this page are redrawn concept illustrations — the real client work stays confidential.

the domain, in a sentence: LGPS is the UK's local government pension scheme — many funds whose asset-management costs ClearGlass analyses and benchmarks. the data arrives as deeply nested fund structures that must be mapped and verified before any analysis can happen.
fig. 01 — the revenue line
Diagram: five scheme boxes converge into a multi-scheme platform, leading to a cobalt box labelled a new revenue line.
decision 01

Build, don't staff

The obvious answer to a growing manual workload is more people — and that was genuinely on the table. But scaling the ops team with the workload ties cost to revenue permanently: every new scheme means new hands. The platform case was structural — automate the processing once, and LGPS revenue could grow while the cost base stood still. That framing, margin rather than convenience, is what carried the investment decision.

the alternative we rejected: scale the ops team with the workload — revenue up, margins flat, forever.
decision 02

Under-engineering on purpose

The engineers recommended full reconciliation engines, and the case was compelling — elegant, complete, correct on the whiteboard. We said no, for one reason: there was too much we didn't know. Before a first real collection cycle, a heavy build would have encoded our guesses. So we deliberately built lighter than we could have, shipped into the cycle, and let the cycle teach us what the second version actually needs.

the alternative we rejected: build the full reconciliation engine first — compelling on the whiteboard, blind to what the first cycle would teach.
decision 03

A new client type, priced as one

LGPS funds aren't corporate pension clients with a different logo. The scheme is statutory, funded and defined-benefit, administered locally by dozens of funds with pooled assets and thousands of participating employers — which is why the data arrives as deep hierarchies rather than tidy tables. We treated that as what it was: a new client type. The platform absorbed the structural complexity, and a new charging scheme was built alongside it rather than stretching the existing commercial model over a shape it didn't fit.

the alternative we rejected: treat LGPS as more of the same clients on the same commercial model.

Where it landed

A new revenue stream for the business, created from what had been pure operational cost. The platform mapped hierarchical structures, visualised data flows and supported transparent verification — and is now scaling on the learnings of its first collection cycle.

The most senior thing we did was under-engineer on purpose.
from: decision 02