When Track Record Global recently brought Starbucks on board as a new client, it was a notable win. What made it possible, though, started three years earlier with a very different name: John Lewis.
TRG is a tech-enabled services and supply chain intelligence company. They assess their clients' products against UK and EU legislation, producing the Product Technical Files (PTFs) that retailers rely on to prove compliance. The work is detailed: suppliers answer questions on provenance, volume, process and other product characteristics, and upload the evidence that backs their claims. And it sits in a regulatory landscape that doesn't stand still, with UK and EU requirements continuing to evolve in parallel.
For years TRG ran on a platform called Track Vision that served them well. But when John Lewis came in as a client, the scale and complexity of the data were on a different level entirely. Rather than stretch the existing system to fit, TRG made a more strategic call: they wanted a platform that would support the business into the future, not just the immediate requirements of one client. They brought us in to build it.
That decision is the reason Starbucks could be onboarded smoothly this year. And it points to something every growing business has to reckon with eventually.
The legacy platform problem nobody plans for
Legacy software rarely fails outright. Instead, it constrains. Exports that should take minutes take hours. Adding a client becomes a project rather than a process. The cost of staying still grows slowly enough that it's easy to ignore until a major opportunity forces the issue.
The temptation is always to patch rather than rebuild. It feels cheaper, faster, lower risk. But patches accumulate, and the gap between what your platform can do and what your business is trying to do widens with every workaround.
TRG made the harder choice. Rather than keep extending a system that was already at its limits, they chose to rebuild it properly, and brought in an external partner to do it. That gave them modern engineering, cloud-native delivery and an agile way of working as core competencies on day one, alongside the visibility into cost and progress that in-house firefighting rarely allows.
Rebuilding with intent
When we rebuilt the platform, the goal wasn't to add features for their own sake. It was to make deliberate engineering choices that would hold up as the data grew richer and more complex over time.
At its core, Track Vision 2 is a data platform. We designed the schema with clear intentions: consistency to keep data quality high, normalisation to protect integrity, and selective denormalisation where it genuinely improved query performance. These are not glamorous decisions, but they are the ones that determine whether a system stays fast and reliable years down the line.
On top of that foundation, we built a component-based user interface in VueJS, supported by Pinia for frontend data management, and a RESTful API on the Play Framework to serve both the user experience and the administrative work of data loading and reporting.
None of this happened in isolation. We spent significant time working alongside TRG's domain experts, because software built without a real understanding of the business it serves tends to solve the wrong problems elegantly.
"TRG built a platform ready for whatever came next. Starbucks is one example of what that looks like in practice."
What good engineering delivers
The clearest way to see what the new platform changed is to walk through what it actually does with TRG's data, end to end.
It starts with what comes in. Suppliers contribute richer, more detailed product information than the old system was ever built to handle. John Lewis alone holds more data than all of TRG's previous Track Vision customers combined, and the new platform is designed to keep accepting more complexity without buckling under it.
That raw input then has to become genuinely usable for TRG's consultants and compliance experts, who need to interrogate, validate and act on it. The platform turns a high volume of supplier evidence into something a domain expert can work with at speed.
Finally, what TRG's clients need is the insight, not the raw evidence. Product Manager, the principal reporting tool, exports a complete set of products in around four minutes. The previous system took many hours to do the same, despite handling far less data. As the reporting needs have grown, we've improved the dashboard's performance by a factor of five.
The infrastructure underneath all of this scales to match what's asked of it. The database scales up to handle heavier reporting demands. The API servers scale out automatically as usage rises, scale back in as it falls, and restart unhealthy instances on their own.
It's worth naming what made this possible. We've been architecting systems this way for over a decade, long enough that these choices feel automatic. That's the point. The performance gains arrived as a by-product of experienced engineers making sound decisions by default, rather than as a series of hard-won battles.
The lesson for any growing business
The story here isn't really about a single platform, or even a single client win. It's about what your infrastructure says yes to.
The investment TRG made three years ago wasn't about Starbucks. They couldn't have known Starbucks was coming. It was about building something capable of carrying whatever came next. Starbucks is one example of what that looks like in practice. There will be others.
Every ambitious business reaches a point where its next opportunity is bigger than its current systems were designed for. The organisations that thrive are the ones that treat their platform not as a fixed cost to minimise, but as the thing that determines which clients they can confidently take on.
