An honest look at our current challenges, what we're doing about them, and what it will take to get to a better place.
The platform we've built over the past 9 years has served us well. It's taken us from zero to 450k+ PAPs and £120M+ in revenue without requiring significant investment in technology or platform infrastructure. But we're now at a point where the gaps and debt we've accumulated need deliberate investment to address.
What follows is an honest breakdown of where we are, what we're doing, and what we still need.
For context: We had 25 incidents in Q4 (Sept–Nov). Roughly half were related to external providers (game providers, payment providers, Cloudflare). The rest were internal — and many of those map directly to the gaps we're addressing.
Migrate from Layershift to AWS — resolve network issues, enable infrastructure-as-code
Replace ageing build system with modern tooling fit for today's world
No one owns the high-level architecture view across all services and squads — issues growing unchecked
Centralise logs and metrics, enable proactive alerting and faster diagnosis
Load testing, performance profiling, staging environment — the foundations
1:1 squad parity, E2E automation on critical flows, free QAs for exploratory testing
No one owns this today — hire specialist, assess posture, establish governance
Lack of product function has stretched tech leadership and impacted squad direction
Layershift has been good value as we've grown, but we're seeing intermittent network issues, deployment inconsistencies, and we can't achieve infrastructure-as-code — everything is manual click-ops.
This isn't a lift-and-shift. We're using the migration as an opportunity to completely rework our build and delivery pipelines to be dynamic, resilient, and flexible.
⚠️ Capacity required: 1–2 backend engineers per squad for a full month in Q1, focused solely on migration work
📊 Q4 impact: 5+ infrastructure incidents in Q4 were directly related to Layershift limitations — connectivity issues, network failures, socket timeouts, service unavailability.
Once on AWS, our new infrastructure-as-code pipelines will still be running through our current build system — an ageing setup that doesn't fit our needs in an AI-powered world where build and deployment tooling has evolved significantly.
After the AWS migration completes, Platform Squad will evaluate modern alternatives (GitHub Actions, GitLab CI, etc.) and select a replacement that better supports our ways of working.
The gap: I used to own architecture across all services. When I stepped back 2 years ago, no one filled that gap. Issues have grown unchecked without anyone owning the high-level view across all microservices and squads.
What we've done: In the last 2–3 months, I've formed an architecture function with three IC architects — Shawn (MrQ Backend), Gonzalo (Frontend), Diego (Games). They're my "Avengers" — I can deploy any of them to zoom into a problem and work with squads to get it done. The impact has already been significant. Imagine if we had more of them.
What we need: I'm still directing them personally, which isn't sustainable. We need a Head of Architecture who can own this full-time: understand our current state, surface the unknown unknowns, identify risks and opportunities, and chart where we need to go. This person would lead the architecture function and free me to focus on broader technology strategy.
📅 Timeline: Hire in Q1. First 90 days focused on assessment and building the architecture roadmap.
Our metrics, dashboards, logs, and alerts are scattered across multiple tools with no unified view. No anomaly detection. When something goes wrong, we're often reactive rather than proactive, and diagnosis depends too heavily on individual knowledge. We've outgrown our current tooling.
Comprehensive observability means: centralised logs and metrics, proactive alerts that catch issues before customers do, anomaly detection, and dashboards that let any engineer diagnose problems quickly — not just the ones who built the system.
📅 Timeline: Q1 is foundation — adopt a mature observability platform (under evaluation). Then 2–3 quarters to achieve comprehensive coverage across all critical player flows. This will require ongoing Platform Squad capacity and squad involvement to instrument their services properly.
📊 Q4 impact: Many Q4 incidents had extended impact because we detected issues slowly or couldn't diagnose root causes quickly. Better observability means faster detection, faster resolution, and smaller blast radius.
Why it matters: A mature Platform Squad provides the shared tooling, infrastructure, and practices that let product squads move fast without reinventing the wheel. They own developer experience, reliability engineering, and the foundations everyone else builds on.
Where we are: Our Platform Squad is only 2–3 quarters old. They're already making significant impact, but we have gaps:
We've only just started. Our current framework tests endpoints in isolation — we need to simulate real player behaviour at scale, especially before peak events.
The architects have pushed this at squad level and it's helped catch bottlenecks early. But it's manual and inconsistent. We need automated profiling on every service, mandated for all squads on the critical path.
Our staging environment doesn't reflect production well enough. We need staging to be much closer to prod so we can properly replicate and test performance issues before they hit customers.
📅 Timeline: Q1 establishes the foundations (framework, tooling, initial automation). Q2–Q3 for mature load testing and profiling across critical paths. Staging-like-prod is a longer effort. Platform Squad leads, but squads will need to invest time instrumenting and testing their own services.
📊 Q4 impact: 3 scaling/performance incidents in Q4 — including critical issues during peak weekender traffic — would have been caught or prevented with proper load testing and performance profiling.
📅 Timeline: Q1 focuses on achieving 1:1 parity, tooling selection, and beginning E2E automation on critical flows. Q2–Q3 expands automation coverage progressively. This is a multi-quarter investment — there are no shortcuts to comprehensive test coverage.
📊 Q4 impact: 6 frontend incidents in Q4 — broken landing pages, CVV fields not loading, affiliate URLs returning 500s, cookie issues — would have been caught by better QA automation before reaching production.
The reality: No one owns cyber security today. We have no dedicated security function, no clear governance, and critically — we don't know what we don't know. This is a significant risk at our scale and in a regulated industry.
What we need: A Cyber Security Specialist in IT Ops. Their first job will be to assess where we actually are, surface the unknowns, and establish proper security governance.
📅 Timeline: Hire in Q1. First 90 days focused on security assessment and identifying gaps. Findings may drive additional work for Platform Squad and other teams in Q2+, depending on what's discovered.
I think we're severely underestimating the impact that not having a proper product function has had on Engineering this year.
It put enormous strain on Tech Leadership (2.5 people) to take on product responsibilities while delivering against targets. We could only focus on a subset of priorities, and even then it felt like we were doing many things in a mediocre way rather than mastering a few.
At times, squads were left without clear direction, trying to deliver against rocks without the product guidance they needed.
This isn't a technology problem to solve — it's context that helps explain why some foundations have slipped, and why Tech Leadership capacity has been stretched thin.
Complete migration of all MrQ services. New pipelines live. Requires 1–2 BE per squad for a full month.
Evaluate and adopt mature observability platform. Begin centralising logs and metrics.
Establish load testing framework, performance profiling baseline, begin staging improvements.
Achieve 1:1 squad parity (final SDET joins Jan). Select tooling. Begin E2E automation on critical player flows.
Hire and onboard. First 90 days: assess current state, build architecture roadmap.
Hire and onboard. First 90 days: security assessment, identify gaps, establish governance.
Head of Architecture — to own architecture full-time, lead the architect function, and surface the unknowns across our platform.
Cyber Security Specialist — to own security governance and assess our current posture.
Platform work needs to be protected in quarterly planning alongside product delivery.
AWS migration alone requires 1–2 backend engineers per squad for a full month in Q1.
Q1 is foundations. We need 3 more quarters of consistent execution on these priorities to get to a genuinely good place.
Platform Squad in particular needs to stay focused on platform work — they're the engine driving infrastructure, observability, and tooling improvements.
Tech leadership cannot continue to carry product responsibilities at this level. We need a proper product function to partner with.
AWS migration (MrQ). Jenkins investigation. Foundations laid across observability, platform, QA. Key hires made.
New build system rollout. Observability coverage expanding. Load testing maturing. QA automation growing. PQ modernisation continues.
Comprehensive observability. Performance testing at scale. Security governance established. Architecture roadmap executing.
Platform maturity achieved. Proactive monitoring. High QA coverage. Clear architecture ownership. Staging closer to prod.
Bottom line: Q1 is foundations. We need 3 more quarters of sustained focus to get to a genuinely good place. By end of 2026, we should have a mature, observable, well-architected platform that can scale confidently.