Most data platforms
get built. Not many
get used.
A €60 billion global energy utility. Fragmented data spread across three markets. Commercial teams making decisions with numbers that couldn't agree with each other. Fourteen months later: 40% less operational overhead, decisions made 5× faster, a new business function deployed across three markets. Presented twice at Vivatech. Built at a fraction of what alternatives would have cost.
The data existed.
The problem was that it didn't agree with itself.
Every market had the data. It lived in different formats, different systems, different people's heads. When commercial leaders needed a view across France, the UK, and the Netherlands — to understand what was working, where to put resources — they were stitching together spreadsheets and hoping the definitions matched. They didn't.
The instinct — build a platform that aggregates it — was right. The harder question was how to build one that people would actually use. And who would stay long enough to make sure they did.
Most platform builds fail for the same reason: the tool gets built and handed over. The handover is where adoption dies. If the teams who needed to use it weren't part of building it, the tool was designed for a version of their workflow that doesn't quite match reality.
That is a different project than building a platform.
We don't consult from the outside. We embed inside.
Our team became part of the client's team. We were in the operational reviews. We understood what commercial leads were actually trying to know, and why the current process for knowing it was broken at a mechanical level, not just in theory.
Before a line of code was written, we generated the business case and took it to executive leadership. Not as a governance formality — a platform without ExCom conviction doesn't survive its first budget cycle. Once that was earned, we worked in two directions: into the operational teams who would use the platform, and up into the commercial and executive teams who needed to trust it.
Without genuine conviction at the top — not sign-off, conviction — a project becomes another internal initiative that gets de-prioritised the moment something else moves. That week always comes. We've seen it.
Fourteen months. Embedded throughout.
Three phases. One continuous thread.
Every Limineer engagement follows the same architecture — discovery to earn the right to build, design to learn before committing, build to ship and stay.
Discovery
Earn the right
to build.
We embedded alongside the organisation before writing a single line of code. The goal: understand the real problem, not the stated one.
We mapped the critical assumptions — on data, governance, team readiness, commercial appetite — and built the business case from the ground up.
ExCom conviction was earned here. Evidence did the convincing.
IN THIS ENGAGEMENT
Business case built and proved to ExCom. Data landscape mapped across all three markets. Governance model scoped before design began.
Design
Build to learn,
not to ship.
Each sprint cycle was designed to generate real conviction — or kill a wrong assumption before it cost six months of budget.
Prototypes were tested with the operational teams who would live with the result. Not user testing sessions — embedded iteration with real workflows.
The platform that exists today looks nothing like the original brief. That is not a failure of planning. It is the only honest way to get to a better answer.
IN THIS ENGAGEMENT
Multiple sprint cycles. Prototypes tested with operational leads in France and the UK before the architecture was locked. Governance model co-designed with the teams who would run it.
Build
Ship it.
Then stay.
Full platform build using dedicated AI development tools and a team trained on the Liminal Process Model — so the product and the process stay connected.
Adoption work started on day one. Four operational teams coached through every stage — not handed documentation and wished luck.
We don't consider a deployment successful until the teams are pulling the platform toward new use cases, not being pushed toward the ones we designed.
IN THIS ENGAGEMENT
Live across France, UK, and Netherlands. Four teams moved from reluctant to championing. Platform shipped continuous updates every quarter since launch.
Two things had to work.
Both at the same time.
The product. And the people who had to change their behaviour to use it.
The Millimeter Shift
The real work is the three-millimeter shift — the moment when someone who has been doing it the old way decides the new way is better for them, not just better in principle. Everyone focuses on the product roadmap. Behavioral change is what actually determines whether the product lands.
Our Forward Deployed Limineers embedded alongside four separate operational teams inside the group — coaching them through adoption, learning their actual workflows, and designing change that met people where they were. Not training sessions. Sustained, on-the-ground work with the people who would make or break the platform in practice.
The governance model wasn't built for an ExCom presentation. It was built for the person running the operational team who has twelve things on their plate and didn't ask for a new platform.
The measure of success: we went from pushing adoption to being pulled. Those four teams are now championing Meta Now inside the group. That shift — from reluctant users to internal advocates — is the outcome most implementations never reach.
Sprints,
not slides
We used our proprietary Liminal Process Model — a science-backed approach to discovering, designing, and building new business opportunities inside large organisations. It's not agile in the generic sense. It's a specific set of sprint cycles, each designed to generate real conviction — or kill a wrong assumption before it costs six months of budget.
Combined with dedicated AI development tools built for this kind of work, we moved fast without losing rigour. Each sprint produced something testable. Each test produced something learnable. The platform that exists today doesn't look like the one in the original brief — because we learned our way to a better answer, which is the only honest way to get there.
What we built: a platform that aggregates data from 23 sources across France, the UK, and the Netherlands, surfaces the commercial signals the teams actually need, and feeds directly into the decisions that drive revenue. The operating model and governance structure were designed to keep it current as the business changes.
"Designed to evolve" was a constraint on the architecture from day one. Systems that aren't built to adapt become the next generation's legacy problem.
Built to be used.
Not just to be built.
What follows is Meta Now — the platform that took 23 data sources across three markets and turned them into the commercial decisions the teams needed to make.
23 data sources
CRM, ERP, logistics APIs, field ops, market feeds — aggregated and reconciled in real time.
Live across 3 markets
France and the UK fully deployed. Netherlands onboarded in month 14. One governance model, one platform.
Designed to evolve
Architecture built for new markets, new sources, and new signal types — not locked to the original brief.
The numbers are real.
So is the function behind them.
Fourteen months of embedded building. One new business function. Three markets live. The metrics below are the output. The capability is what stays.
Compared to the alternatives — large consulting firms who would have designed the same thing from the outside and handed it over around month six — this was done at a fraction of the budget. The difference isn't the output. It's who stayed for the adoption.
Both audiences had to be satisfied.
Both were.
A platform that executives believe in but operational teams don't use is a shelf product. We designed for both — and measured success by both.
Meta Now is a tremendous benefit to our work — and it's helping us gain visibility inside the organisation we didn't have before.
Operational Team
Market lead, deployed market
It's helping us compete in a fast-moving market segment and introducing the organisation to more aggressive, more competitive ways of operating.
ExCom Layer
Executive committee, global level
They own the IP.
We keep it alive.
The biggest risk in any platform build isn't the architecture — it's what happens the day after handover. We designed this engagement so that day never comes.
The License Model
The client retains full core IP ownership. Limineer provides the platform infrastructure, product development, and adoption support as a licensed service — on an OPEX fee tied directly to the business case we defined together.
If it's not working, we're not doing our job. There is a performance element. That's not a contract clause — it's how we think about accountability.
What the Client Gets
Continuous product development — major updates shipped every quarter. Technology doesn't depreciate the moment it goes live.
Embedded adoption support — Limineers stay involved to ensure the platform evolves with the teams using it, not ahead of them.
Full repatriation option — the license can be pulled in-house at any point. Maximum flexibility as the organisation builds capability.
Technology built and handed over starts depreciating on day one. Two months in, the underlying stack may have shifted. Six months in, the team that built it has moved on. The license model exists because we've seen what happens when it doesn't — and we're not interested in building something that becomes a liability.
Not a tool. A function.
This organisation now has a new business function. Not a platform that gets used — a function, with a governance model, operational teams who run it, commercial teams who trust it, and an ExCom that treats it as a competitive asset.
Four operational teams that started as adoption targets are now the platform's loudest internal advocates. That shift — from pushing change to being pulled by it — is the outcome most implementations never reach. It's also the one that determines whether a platform survives its second year.
Most "successful deployments" are successful builds. The adoption is left as an exercise for the client. We don't separate the two. The adoption is part of the build — and it starts on day one.
The decisions that used to take a week of data reconciliation now take an afternoon. With better data underneath them. Across three markets. Every week.
10 — If This Resonates
If you're looking at a similar challenge — we're interested in that conversation.
Not to pitch a solution before we understand your situation. Not to show you a methodology deck and leave you to implement it. To compare notes on what you're actually dealing with — fragmented data, commercial teams flying on incomplete information, platforms that got built but didn't quite land. We've been in that room more than once. It usually looks different from the outside than it does from inside.
Start a conversation