Platform Engineering Reality Check: Three Case Studies in Turning Big Dreams Into Practical Steps 

I think I’ve spoken at every single PlatformCon since it started, and every year I notice the same gap. On stage, platform engineering sounds like a solved problem: Self-service everything, developers and AI agents shipping in minutes, no friction anywhere. In the day-to-day of running Syntasso and working with our customers, it looks a lot messier than that. My talk at PlatformCon 2026 was a deliberate reality check. Less hype, more of what I’m actually seeing across the organisations we work with. 

Why Platform Dreams Stall Before They Start 

Most platform initiatives start the same way. Someone has watched the conference talks and heard the hype, and now wants a seamless, fully self-serve developer platform for their engineers and, increasingly, their AI agents too. 

Then reality sets in. You’re rarely starting from a greenfield. You’ve got legacy tech, legacy processes, and a list of platform concerns (security, observability, networking, and on) that never seems to end. And for every item on that list, there are multiple technical solutions already in use somewhere in your organisation. Glance at the CNCF landscape, and you’ll see exactly what I mean: an overwhelming wall of choice for every layer of the stack. 

That amount of choice doesn’t feel like freedom. Teams try to gather every requirement up front, and it’s all too easy to get buried under the sheer weight of it all and then nothing ships. 

Platform as a Product, Not a Wish List 

The way out of that trap is a mantra most of you will have heard by now: Platform as a product. My team has even written a book about it. I’ve said this before, and I’ll keep saying it, because it’s genuinely this simple: Apply the same product management discipline to your internal platform that your organisation already applies to its external, customer-facing products. 

In practice, that means a few specific things. Understand your users. Your platform’s customers are developers (and increasingly AI agents), so think about their experience the way you’d think about user experience for any product. Find one friendly team who’s willing to be your first user, work closely with them, and get their feedback as fast as possible. 

Then build something small. In product management, we talk about a minimum viable product. In platform engineering, we talk about a minimum viable platform: Just enough capability to put in front of that first team so they can actually use it and tell you what’s missing. Take what’s working and do more of it. Fill the gaps. Fix what isn’t landing. Repeat. 

That’s the theory. Here’s what it actually looks like at three organisations we’ve worked with recently. 

NatWest: From 8 to 10 Weeks Down to 35 Minutes 

NatWest is a UK bank we’ve been working with for a few years, and it’s about as far from greenfield as it gets: decades of legacy, a lot of complexity, heavy regulation. Their end goal is an internal platform that’s fully self-serve, with standardised deployments and a much shorter lead time for developers. 

They didn’t start by building all of that. They started with the one problem hurting the most people: it was taking 8 to 10 weeks to stand up a Kubernetes cluster on AWS. They found a team that didn’t want to manage its own infrastructure, built a minimum viable platform around that single need, and got the time down to 35 minutes. NatWest’s own case study has more, and two of their engineers have also spoken publicly about the journey at a recent KubeCon co-located event. 

Next for NatWest is widening what the platform can handle, plus exploring how it supports AI workloads. But notice what got them here: one sharply defined problem, one willing team, and a number that moved from weeks to minutes. 

The Access Group: Proving it With a Hackathon, Not a Roadmap Slide 

The Access Group has an internal AI development platform called Evo Builder that lets teams generate application code extremely quickly. That speed created a new problem: How do you run all of that AI-written code safely and reliably? That’s where their platform came in, built on Kratix. 

Phill Morton, who shared an early view into their case study at KubeCon, describes it as giving the platform “constructive constraints”: built-in guardrails that shape what AI-generated code is allowed to do, rather than trying to review every line by hand. It’s a phrase I keep coming back to, because it captures something a lot of AI platform conversations miss. 

They didn’t roll this out gradually. They proved it with a three-day hackathon across multiple teams and time zones, and the feedback was clear: the platform was an enabler, not a bottleneck, even at that pace. A week after the hackathon, the platform was already running over 1,000 applications. It now hosts more than 2,000. 

A Large Financial Services Firm: From 4 Weeks to 6 Minutes 

I can’t name this one yet, though I’m hopeful they’ll write up their own case study soon. It’s a large US-based financial services organisation with problems that will sound familiar: Slow manual processes, long deployment times, and big ambitions, including expanding into new regions while driving down technical debt and operational overhead. 

Their approach has been the most methodical of the three. They started with a small proof of value: take one application, migrate it to the new platform, and measure the change in deployment time. It went from 4 weeks to 6 minutes. They’re now running an extended production proof of value to test whether that result holds up at scale and repeats across different applications, before building out the reusable patterns that will let the platform grow with their global plans. 

What All Three Actually Have in Common 

None of these organisations picked a wildly different starting point. Each one narrowed in on a single, well-understood use case: NatWest and the team that didn’t want to manage its own infrastructure, The Access Group and supporting its global hackathon, the financial services firm and one slow application. In every case, they knew who they were building for, what was hurting them, and how they’d measure improvement. That’s also why feedback came so easily: They already knew which team to ask, so they didn’t have to go hunting for it. 

At least two of these organisations are now talking about it publicly. NatWest and The Access Group have both written blogs and spoken at conferences about what they’re building and how, and that visibility is driving curiosity, even a bit of FOMO, inside their own organisations. All three are sharing progress internally too, through communities of practice or plain old demos. 

Final Thoughts 

In a nutshell, building successful platforms is primarily about focusing on users, iterating quickly, and gaining adoption by doing things that may not scale. Serve your users by knowing who you’re building for, what’s actually blocking them, and how you’ll measure improvement. Release early and often. You need real feedback that you’re building the right thing, not just the things you dreamed up on a whiteboard. And win people over with concierge or “white glove” experiences combined with some lightweight “marketing”. Visible wins drive adoption more reliably than any roadmap slide ever will. 

Do those three things and your platform dreams stop being dreams. They might not end up looking exactly like you first imagined, and that’s fine. None of the organisations I’ve mentioned here started with the full picture either. They started with one problem worth solving. 

If you want to talk platform as a product, find me on LinkedIn. I’m always happy to compare notes.