featured image

Today the title becomes official: Software Architect, Games Platform — with the role of Lead Architect for Jackpots — at Derivco.

It’s a step I’ve been walking toward for a long time, and one I want to mark properly. Not with a victory lap, but with a bit of honesty about the road that led here, the people who made it possible, and what I’m planning to do with the chair now that I’m in it.

Make the engineers around you faster.

Across very different stacks and very different scales, that’s been the through-line for 15 years. The title changes. The instinct doesn’t.

Five chapters, one company 📖

I joined Derivco in January 2007 as a tester. I’m writing this in May 2026. Same company, very different person. The 19-year arc isn’t really one career — it’s five chapters, each shaped by a different platform and a different scale problem.

Chapter 1 — Tester, then Senior Tester (2007–2013)

I started in QA on one of the largest independent poker networks in the world. ISEB Test Analyst (2009), then a string of internal awards — Tesla Innovation Award (2010) for tooling that gave devs and testers genuine superpowers, Best Overall Performer (2011), Da Vinci Innovation Award (2012) for a web app that took the friction out of cross-team work allocation.

Looking back, the pattern was already there in those first awards. Both were about the same thing: the people around me were brilliant; my job was to remove the things slowing them down.

That instinct never left.

Chapter 2 — Developer, Dev Lead, Tech Lead, Poker Client (2014–2018)

Cross-platform delivery to Web, Android, Windows and Mac. Squads in two countries. Real-time client at scale.

The architectural moves I’m proudest of from this chapter:

  • WebSockets + SharedWorkers for client connection multiplexing — one socket per browser instead of one per tab.
  • A tournament list performance rewrite that supported 3,000+ concurrent tournaments without buckling.
  • An external tournament lobby that decoupled discovery from the heavyweight client.
  • An SDLC re-architecture so the client could be reconfigured at runtime — without re-rolling a build for every config tweak.

That last one is the one I still bring up in interviews. It wasn’t glamorous. But it gave the team back weeks of cycle time, every release cycle, forever. That’s the work I love.

Chapter 3 — Acting as Architect, Game Management & Aggregation Platform (2020–2025)

This was the chapter where the work was architecture, even though the title hadn’t caught up yet. Officially I was acting in the role; unofficially I was making the calls.

A cloud-native game management and aggregation platform spanning an entire iGaming estate. Hybrid hosting across Azure cloud and regulated on-prem sites. A multi-phase Business Value programme covering bet-settings governance, game-delivery streamlining, single-source-of-truth metadata, and universal game aggregation.

The hardest and most rewarding part: strangler-replacing multiple legacy systems with zero downtime. The estate could not stop running. Players don’t care about your migration plan. The new platform had to ship in slices, behind feature flags, with the ability to fail back instantly — and the legacy could only be retired one outbound integration at a time.

It taught me that big-bang rewrites are a fantasy and that good architecture is mostly about what you choose not to break.

Chapter 4 — Acting Architect, Cross-Pillar (2024–2025)

A bridge chapter, and an honest one. Still acting in the role rather than holding the title — this time on the cross-pillar work to separate game-server and player-account responsibilities and introduce a next-generation game-hosting platform, without disrupting the live wallet and player-account estate.

Some of what we set out to build didn’t ship in the form we first designed. Pieces of it got paused, rescoped, or restarted along a different path entirely. That’s not a footnote — it’s most of what made this chapter valuable.

The hard lessons:

  • Sequencing beats sequencing. A technically elegant plan that lands ahead of the organisational readiness for it will get overtaken by a less elegant one that lands at the right moment.
  • Architectural integrity at organisational scale is mostly negotiation. How to draw a boundary that survives team reorgs. How to write a decision record that’s still useful in two years. How to negotiate sequencing across pillars when everyone has a legitimate priority and finite engineering capacity.
  • A restart isn’t a failure if the second version is better. Some of the components we paused came back stronger because the first attempt forced clarity on what they actually needed to be.
  • Less code, more conversations, more writing, more listening. This is the work, not a distraction from the work.

This was the chapter that prepared me for the new role — not because everything went smoothly, but because it didn’t.

Chapter 5 — Software Architect, Games Platform / Lead Architect, Jackpots (2026 →)

And here we are.

Progressive jackpots is one of the highest-stakes domains in iGaming. Real money. Real regulators. Real players who will absolutely notice if a million-dollar prize doesn’t behave correctly. The systems are high-volume, latency-sensitive, and unforgiving — exactly the kind of place where architecture earns its keep.

The focus areas going in:

  • Platform modernisation in place — no rewrites, no big bangs, no breaking what already works.
  • AI-first delivery — making AI-assisted development a first-class part of how the team ships, not a side experiment. (More on this below.)
  • Distributed-systems architecture — the unglamorous foundations: idempotency, observability, backpressure, replayability.
  • Architectural integrity — keeping the platform coherent as it evolves under pressure.

Same instinct as 2010. Just a much bigger surface to apply it on.

The AI thread 🤖

A few people have asked why “AI-first” keeps showing up in everything I’m writing this year. The honest answer: because it’s the biggest leverage shift I’ve seen since cloud, and I’d rather be early and useful than late and defensive.

Earlier this year I shipped a production Model Context Protocol (MCP) server that exposes enterprise game data to Copilot and Claude Code — turning AI agents into first-class participants against real enterprise systems, with proper auth and audit. It’s the most “make the engineers around me faster” piece of work I’ve done in a decade. Same instinct, completely new substrate.

That’s the bet for this chapter: AI agents become a permanent part of the engineering org chart, and the architecture work is making sure the rails are there for them to do their best work safely.

How I got here ❤️

Honestly? Mostly by being lucky enough to work alongside extraordinary people for a very long time.

Derivco has a culture of giving people room to grow into harder problems before they technically “deserve” them — and trusting that they’ll figure it out. I’ve been on the receiving end of that trust, repeatedly, for nearly two decades. Every chapter above happened because someone in leadership made a bet on me that I hadn’t yet earned. I want to repay that, now from the architect’s chair, by making the same bet on the people coming up behind me.

A specific list of thank-yous would be both very long and unfair to whoever I forgot. So instead: if we’ve ever shipped something together, debugged something together, disagreed about an architecture decision, paired on a tricky bug, or sat through a meeting we both found pointless — thank you. This title is partly yours.

What’s next 🚀

A few things I’m committing to publicly, so future-me can be held to them:

  1. Write more in the open. Long-form architecture notes have lived inside the company for years. Some of them deserve a public stream. They’ll start appearing here as soon as something can be shared without compromising the platform.
  2. Keep building the AI rails. The MCP server is one node in a much bigger graph. There’s a lot more to do on making AI agents safe, useful, and audited against real production systems.
  3. Stay close to the code. The fastest way to lose architectural credibility is to stop reading the codebase. Not happening.
  4. Make the engineers around me faster. As always.

If you’d like to keep up with what I’m working on:

  • The full professional picture lives at andrewbevan.me/about.
  • Architecture notes will land here on the blog as I write them.
  • The shortest path is usually LinkedIn.

Onwards. 🚀