How The Access Group Scaled AI-Driven Development with Platform Engineering

It started, as these things often do, with a deceptively simple problem: how do we host the applications being built on our new AI-powered development platform, Evo Builder?

Evo Builder is designed to let anyone, not just engineers, build applications through natural interaction. The early thinking around hosting was predictable: use Terraform, maybe even have AI generate the infrastructure code dynamically.

On paper, that sounds like the future. In practice, it raises a harder question: what happens when you let AI freestyle your infrastructure?

The Access Group's "Access Evo" Platform

The Problem with “AI-Generated Everything”

There’s a growing narrative that AI will remove the need for structure in software delivery; that you can simply prompt your way to production systems.

But infrastructure isn’t just about getting something running. It’s about consistency, security, scalability, and the ability to evolve over time. When every output is generated from scratch, you lose the guarantees that platforms are designed to provide.

Terraform is powerful, but it operates at a relatively low level of abstraction. If you combine that with AI generating configurations on the fly, you risk creating a system that works… until it doesn’t. Drift, duplication, and rework become inevitable.

That’s why I proposed a different approach: instead of letting AI generate infrastructure directly, we should give it a structured platform to work within.

Enter Kratix: Bringing Order to AI

Kratix gave us a way to introduce what I’d call constructive constraints.

At its core, Kratix allows you to define abstractions, “Promises”, that represent the capabilities of your platform. Instead of asking AI to generate infrastructure, you ask it to work within those abstractions. This changes the dynamic entirely.

AI is no longer responsible for inventing infrastructure patterns. It’s operating within a system that encodes best practices, organisational standards, and operational knowledge. It becomes another customer of our platform. For Evo Builder, this was critical, as we weren’t building a platform for a handful of engineers. We were building something that would allow non-engineers to “vibe code” applications and rapidly create and iterate on ideas without needing to understand hosting, networking, or deployment pipelines.

Behind the scenes, those applications still need to run somewhere. They still need to be secure, scalable, and reliable. Kratix became the layer that made that possible.

From Internal Tool to Global Hackathon

Shortly after pitching this approach, I was pulled into a conversation with our CEO and CTO. The question was simple: Could Evo Builder support a global hackathon across the entire company?

Three days. Multiple time zones. Every department. Potentially thousands of applications being built and deployed in parallel.

The obvious answer was yes. The realistic answer was: only if the platform holds up under pressure.

At that point, Evo Builder was focused on the build experience. The hackathon proved that anyone in the organisation could create applications through natural interaction. But the applications had nowhere to go. Deployment wasn't part of the picture yet. The hackathon validated the demand; the next challenge was giving those applications a home.

This is where the combination of AI and platform engineering really proved its value.

Scaling with Structure, Not Chaos

Because we had introduced Kratix early, we weren’t scaling a collection of ad hoc infrastructure definitions. We were scaling a platform with clear abstractions.

Each application deployed through Evo Builder was mapped onto a defined Promise. That meant:

• Consistent environments across all applications

• Built-in governance and guardrails

• The ability to evolve the platform without breaking existing workloads

Instead of managing thousands of unique infrastructure configurations, we were managing a set of reusable capabilities.

This is the difference between scaling effort and scaling systems.

AI played a key role in enabling users to build applications quickly. But it was the platform, structured through Kratix, that ensured those applications could be deployed and operated reliably.

Enabling Engineers to Own Their Flow of Value

One of the most interesting outcomes has been the way the platform has changed how engineers interact with infrastructure day-to-day.

Engineers have been making changes to the platform without my involvement. Traditionally, that might mean navigating complex Terraform configurations or coordinating across teams. Instead, they update the relevant Promise in Kratix, watch the continuous reconciliation take effect, and see their changes reflected in real time. That feedback loop has genuinely impressed the team. There's something powerful about making a change and watching the platform just respond.

That's the shift that matters. When you provide the right level of abstraction, you don't just make systems easier to use; you make them easier to own. Engineers can take responsibility for the parts of the platform that matter to them, evolve those capabilities independently, and own their flow of value.

2,000 Applications (and Counting!)

The hackathon was just the beginning. Since then, we’ve opened up Evo Builder more broadly, and within a week, we were hosting over 1,000 applications on the platform, all deployable with a single click (and now we're hosting over 2000). That kind of growth doesn’t happen by accident.

It’s the result of combining two forces:

• AI, which lowers the barrier to building software

• Platform engineering, which ensures that what gets built can scale

But the key insight is this: AI alone isn’t enough.

Without structure, AI introduces variability. With the right platform, it introduces velocity.

Why This Matters for C-Level Leaders

For organisations investing in AI, there’s a temptation to focus purely on productivity gains, i.e., how quickly can we generate code, build features, or prototype ideas?

Those gains are real. But without a platform strategy, they don’t compound.

What we’ve seen with Evo Builder is that the real value comes from pairing AI with a well-defined platform layer. One that provides:

• Guardrails without slowing teams down

• Abstractions that evolve with the business

• A clear path from idea to production

Say Yes to the Slightly Terrifying Things

Looking back, the decision to run a global hackathon on a rapidly evolving platform was, on some level, slightly terrifying. But those are often the moments that force clarity.

They expose the weaknesses in your approach and validate the strengths. In our case, they reinforced a simple idea: if you want to scale AI-driven development, you need to give it structure.

Kratix gave us that structure. Evo Builder gave us the interface. And together, they allowed us to turn a hosting problem into a platform that’s now powering thousands of applications.

None of that happens without saying yes, and having the right people and technologies around you when you do.