Where we're going, and why every step follows
We are on a mission to make modding easy. Adding a mod to a game should be as simple as adding a song to a playlist. The platform strategy exists to serve that mission and nothing else. We are not modernising to show users we modernised. We modernise where it makes the mission faster: composable primitives the ecosystem can build on, install journeys that resolve, deploy, validate and recover, and a codebase where humans and AI agents ship in small steps, every day.
This document is written as chains of consequence. Each commitment follows from the one above it, and where a chain reaches a real decision, the decision is named rather than hidden.
Standing principles (already decided)
Every pillar is a chain: a goal, then the consequences that follow, down to the point where a real decision has to be made (marked ◆). This is also how we want prioritisation argued day to day. A worked example, including what happens when a link breaks:
Chains are living arguments. When facts change, the conclusion changes, and saying so out loud is the point. If you can't chain your work back to a pillar, either the strategy is missing something (raise it) or the work shouldn't be done yet.
The four pillars
- One language across web, Vortex and backend: shared types end to end, one toolchain, one set of conventions.
- The doctrine wants a stack any developer in the company can work on. Today backend Ruby is a separate world from everything else we write.
- Static types help both refactoring confidence and AI agents, without repeating the Sorbet experiment of bolting types onto Ruby.
- Larger hiring pool, and one pool instead of two.
- Rails is unusually productive for exactly this product: CRUD-heavy, payments, background jobs, admin. The TS backend world has no Rails; you assemble the batteries yourself and the ecosystem churns.
- We pay twice: consolidate into Rails, then strangle Rails into TS. The failure mode is a decade of two backends.
- The backend bench is thirteen-plus engineers deep in Ruby, and we are hiring more Ruby seniors right now.
- AI cuts both ways: agents write good Ruby, and tests plus generated contracts deliver much of what types promise. The strongest technical argument for TS is weaker than it was two years ago.
Review group: this is the pillar to attack. If the counter-arguments win, the honest alternative is "Rails is the endgame, TS stays frontend and clients", and the strategy still works. What we will not do is leave it undecided while both worlds grow.
- The cluster works and carries enormous read traffic. The operational knowledge exists.
- Most of today's pain is Flamework coupling (schema changes across three repositories), which the monorepo and Flamework retirement remove without moving a single row.
- A migration is 18 to 36 months of dual-write and parity validation for near-zero user value. The mission is modding, not engine purity.
- Schema cleanup (legacy columns, missing constraints) can happen in MySQL without a migration.
- Under this position: Postgres is the default for new work, Galera remains first-class with no retirement date, and a specific dataset moves only when a product problem justifies it.
- Two engines forever means two backup regimes, two upgrade cycles, two failure modes, two sets of expertise, in a team that wants fewer of everything.
- The June assessment called the legacy schema the riskiest part of the estate. Constraints and FK enforcement are cheaper to get right once, in one engine.
- Once Flamework retires, the monolith owns every query, which is precisely when moving data is cheapest. Declining to name even an undated end state forfeits that moment.
- Under this position: same practical behaviour as A for years, but the stated destination stays "one relational engine", so every schema decision leans that way.
Review group: pick one. Both positions agree on the next two years (Postgres for new work, no dated migration, fix the coupling). The disagreement is only about what we say the end state is, and what that does to daily schema decisions.
What we are explicitly not doing
No new services (doctrine, enforced). No full rewrite. No types bolted onto Ruby; the Sorbet experiment is over and refactoring confidence comes from tests and contracts. No new features in Flamework except urgent, low-risk changes with a cleanup ticket. No dated promises on migrations whose pace depends on capacity we have not secured. And no modernisation for its own sake: if a piece of platform work cannot chain back to making modding easier or making delivery faster, it waits.
Roadmap: sequence over dates
The sequence is the commitment. Dates are forecasts and we don't publish forecasts as promises, internally or externally. Now is in flight, Next starts when Now finishes, Later is sequenced but unscheduled, Direction is where the chains point. Decision points are marked ◆ and statuses come from Linear as of mid-August 2026.
Capacity, honestly
Everything on this page is carried by the feature pods and Platform Engineering under the embedded model: each item gets a home pod and an explicit share of cycle capacity agreed at planning, per the Capacity tab. The pace of this page is therefore set by how well that model holds. If platform work starts losing to features cycle after cycle, the register grows, the tripwire fires, and the dedicated-capacity question goes back to exec with evidence. AI enablement (Pillar 2) is the one lever that improves pace without new headcount, which is why it sits so early in the sequence. The Vortex lane summarises the app team's own roadmap; the full document is the source of truth for its sequencing.
Funding the platform work inside the feature pods
Revised August 2026 after discussion with the GM. Baked into the strategy so the two documents cannot drift apart. An earlier draft proposed two dedicated platform pods; this version adopts the GM's direction that platform work stays tied into the feature pods, and names the risk that creates.
Recommendation
Platform and enabling work stays inside the feature pods, but funded and visible instead of absorbed. Every platform initiative gets a home pod and appears on that pod's mission with an explicit share of its cycle capacity, agreed at planning rather than left over after features. Platform Engineering keeps the truly cross-cutting infrastructure and grows only by the intake already signed off. Pods five and six, when they come, are feature pods as the Vision and Mission names them, and the platform work distributes across all six under this model.
This is the same spend this paper has always described. What changes is that it stops being invisible. The one risk the embedded model carries is drift: cross-cutting work with no natural feature home losing to features every cycle, which is exactly the history documented below. The tripwire for that is set out under The honest risk.
The objection to answer first
"Why are we doing this much platform work when what we want is more features?"
Fair question, and the answer is not "trust us". The platform work splits in two. Forced work has a date or a consequence attached whether we fund it or not: framework end-of-life upgrades, security remediation, key rotation, scaling cliffs. We do not choose this work; we only choose whether it is planned or whether it interrupts. Chosen work is investment: consolidation (three APIs to one, four permission systems to one), developer experience, simplification. Each of these has a return we can state and increasingly measure; the Cost Model tab prices the biggest ones.
Nothing here is being snuck in day to day. Engineering labels this work itself in Linear, the totals below come from those labels, and this paper exists precisely to bring the spend above the line and put a decision on it. The choice in front of exec is not whether this work happens. It already happens. The choice is whether it is funded and owned, or whether it keeps displacing features quietly.
On sizing: the only precisely sized items today are the GTA5-Mods Rails upgrade (about seven weeks) and the wallet merge (fifteen to nineteen dev-days); everything else is a project name. Before the exec decision, tech will put rough order sizing against the named list in Appendix A and mark which items are forced. If a third of two pods' output is going on this, exec should see its shape, not just its existence.
The capacity we are already spending
Roughly one in three completed tickets in the two biggest pods this year was platform, risk, or debt work rather than a feature. Engineering labels it itself, in Linear, under the initiatives Engineering risks and Engineering continuous improvement.
That figure is a floor, not a ceiling. The endorsement-processing work, in flight since June, was not originally labelled into those initiatives, and a sweep will likely surface more sitting under feature labels. We will run that sweep before this goes out, for two reasons: it strengthens the number, and the success measures at the end of this paper are built on the same labels, so the labels have to be trustworthy.
Four examples of what the spend looks like in practice: the GTA5-Mods Rails 4 to 8 upgrade, one engineer for about seven weeks including building a test suite from near zero; the Temporal workflow migration, funded entirely out of one feature pod's capacity; Vortex release operations, 82 completed tickets across five releases with the release mechanics re-ticketed every cycle while the automation that would end it sits in a backlog; and the wallet merge into nexus-api, fifteen to nineteen dev-days and a prerequisite for the store work product wants.
About half of the ninety-odd projects inside those two initiatives have no completed work at all. That is the unfunded remainder: stack and data-structure simplification, the endorsements follow-on work, the composite-ID migration, and the rest of Appendix A (the full named list, forced items marked). We already pay this cost. We pay it out of feature capacity, cycle by cycle, without it ever being sized.
What that costs us
Feature delivery is displaced. Creator Experience stepped back from the workflow engine, Upload API improvements, and the next wave of upload form work in the same cycle it took the Rails upgrade as a goal.
Platform work is renegotiated rather than delivered. The OS for UGC direction was signed off across product, design and tech on 7 July, but its platform work was never sized or allocated, so it competes with features inside a pod every cycle. Release mechanics are re-ticketed every cycle for the same reason.
Everyday delivery is slower, for people and for AI agents alike. This is the heart of the AI enablement case and it gets its own section below.
Duplication accumulates. Three APIs and four permission systems are maintained at once, and each new feature is built against whichever is nearest to hand, so the cost rises rather than holding steady.
AI enablement is a codebase problem, not a training problem
This is the part of the paper most easily missed by a non-technical reader, and it is the biggest selling point in it.
The common view is that AI enablement means upskilling each person on the tools. Upskilling helps and we are doing it. But the binding constraint is not the people, it is the codebase. An AI agent works exactly the way an engineer works: make a change, run the tests, read the result, go again. Its productivity is set by the speed of that loop, and today the loop is slow for everyone:
· The API test suite takes over ten minutes to run locally.
· Nothing can be tested without the whole development stack running: database, search, environment config.
· A Rails boot precedes any task, and a Next page compile takes around thirty seconds locally with inconsistent hot reload.
· Review stacks come up with thin data and first-load errors, so engineers fall back to testing in production behind feature flags.
· Search indexing is manual enough that teams design around it, and one consumer exception can take down the shared message connection for everyone.
For a person, a ten-minute suite is an annoyance. For an agent, it is the difference between six attempts an hour and sixty. Every item above throttles agents harder than it throttles people, and as agent share grows the cost compounds rather than holds steady.
Put a number on it: if forty engineers lose forty-five minutes a day to these loops, that is roughly five full-time engineers' worth of capacity burning continuously, before counting a single agent. The Cost Model tab makes every assumption a slider, so anyone who disagrees with a number can move it and see what changes.
And this investment demonstrably pays back. The Q2 developer survey (sixteen developers, April 2026) shows what happens when loop work is funded: overall developer experience 6.4 to 7.4, CI/CD 5.5 to 7.1, devspace startup down to about three minutes with unprompted praise, and RSpec sharding cut CI runs from nineteen minutes to eleven. The Cost Model excludes everything already fixed; it prices only what remains.
"Would AI enablement make up for the extra headcount?" The honest answer is partially. Fixing the loops raises the throughput of every engineer and agent we already have, which is why it is the first lever and the cheapest one. What it does not do is create the scarce expertise in Appendix B, lead pods, or review one-way-door decisions. AI multiplies the team we have; it does not substitute for the few capabilities only one or two people hold.
Two further returns land alongside AI enablement, and both matter this autumn. More engineers can work full-stack: once the stack stops being three APIs and four permission systems, a backend engineer can pick up frontend work and vice versa, which is the versatility the doctrines call for. Onboarding gets faster: around a dozen starters arrive between August and October, including the Head of Backend, and every hour of setup friction and every piece of tribal knowledge is multiplied by each of them. A codebase an agent can navigate is a codebase a new hire can navigate.
This is what pods five and six actually buy: not tidier code, a faster company.
How the embedded model works
Every platform initiative gets a home pod. The named list in Appendix A stops being a shared backlog and becomes assignments: each item lives on one pod's mission, chosen by fit (the pod that owns the surface, or benefits most). Migrations get the pod's own product, design and community seats, which a separate functional team would lack: product sequences against feature plans and owns breaking-change communication, design carries the surfaces migrations touch, community handles users when behaviour changes.
The allocation is explicit, not residual. Each pod agrees a share of cycle capacity for its platform work at planning, visible in the cycle goals, sized in the same breath as features. The share differs per pod and per quarter; what is not allowed is zero by default or platform work living only in the gaps.
Platform Engineering keeps the truly cross-cutting pieces. Infrastructure, CI/CD, observability, devspace: the things with no product surface. It delivers when it owns work outright (the Nginx end-of-life migration in April took no feature-pod capacity at all) and it grows only by the intake already signed off, one platform engineer and one senior platform engineer among them.
The unassigned list is the test. The register's cross-cutting items with no natural home, three APIs to one, permission-system convergence, the monorepo execution, composite IDs, get adopted by a home pod at a quarterly platform review, or consciously deferred with a name against the deferral. Nothing stays unowned silently; that is the drift this paper documents.
One person owns the register. The Technical Director tracks the whole picture across pods: what moved, what stalled, what the trend is. The quarterly review is where adoption, deferral and re-prioritisation happen, with exec visibility.
The capability risk
Four dependencies sit with one or two people each: dependency resolution and the resolver's core, malware reverse engineering, low-level file formats and archives, and Vortex client telemetry, which nobody owns while three pillars are blocked on it. Appendix B has the full picture (six capabilities, held by at most two people each).
Those same people carry the migrations. A cycle spent on a Rails upgrade or a release is a cycle the resolver and the malware work wait, and only they can do either. AI enablement amplifies scarce expertise; it does not create redundancy. Nor do we have a job description, band, or career path for modding and reverse-engineering expertise, the capability that differentiates us: our deepest modding technologists are titled app developers and backend engineers. Specialists should spend their time on specialist work rather than absorbing general platform work.
The honest risk, and the tripwire
The embedded model's failure mode is the very history this paper documents: under pressure, embedded platform work loses to features, gets renegotiated every cycle, and the register grows. We are choosing this model with eyes open, so the guardrail is explicit. The allocation is visible in cycle planning, the register trend is reviewed quarterly, and the tripwire is two consecutive quarters of the register growing or forced work slipping. If that fires, the dedicated-capacity question comes back to exec with the evidence in hand, not as a complaint but as a measured result. Until then, embedded is the model and we make it work.
What we get back
The spend the pods already carry becomes visible, owned and sized instead of displacing features silently. Cross-cutting work stops being nobody's job. The engineers who hold the scarce capabilities get their attention back as the named list shrinks. More of the team can work across the stack, the autumn intake ramps faster, and every feature pod keeps its full mission, which is what the GM asked for.
What this competes with
Product want a dedicated activation pod, and tech does not yet see exactly what Product mean by the OS for UGC, which needs resolving before capacity is committed against it. Trust and Safety want a dedicated trust-and-safety pod. The Content team want better tooling and have not asked for a pod. We are performing well on most KPIs, though eMAU growth is not where we hoped. The embedded model sidesteps most of this competition: it asks for governance and visibility, not new pods.
Sequencing and constraints
The intake is already signed off and arriving: a platform engineer and a senior platform engineer, a senior backend engineer, a principal backend engineer as tech lead, a principal app developer for Electron, and two senior app developers, alongside the Head of Backend in October. Leads remain the binding constraint for any future pod, and the principal hires build that bench. Growth beyond the current commitment is on hold until commercial performance is assessed in Q3 and Q4 and these hires are onboarded and ramped. No dates are attached to any of this on purpose: sequence is the commitment.
Decision required
Exec ratifies: the embedded model; that each pod's platform allocation is agreed at planning and visible in cycle goals; the quarterly platform review; and the tripwire. Tech commits: the named list in Appendix A with a home pod and rough sizing against every item; the labelling sweep that keeps the numbers honest; and the measures. Success looks like: the register trending flat or down, forced work landing planned rather than as interruption, and platform outcomes progressing without cycle-by-cycle renegotiation. If the tripwire fires instead, that evidence comes back to exec.
Appendix A: the platform work the pods carry
The named list. Items marked (forced) have a date or consequence attached whether funded or not. Under the embedded model every open item gets a home pod and rough order sizing before the exec decision; unassigned items get adopted or consciously deferred at the quarterly review. Completed or in progress in 2026:
| Project | Pod or team |
|---|---|
| Wallet into nexus-api merge (prerequisite for the DP Store work) | Blue Shell |
| Endorsement processing rework (in flight since June; previously unlabelled, sweep pending for more) | In flight |
| Temporal / advanced upload workflow | Blue Shell |
| GTA5-Mods Rails upgrade, 4 to 8 (forced) | Blue Shell |
| Commands refactor across Rails projects | Blue Shell |
| Collection bundle upload: large bundles | Blue Shell |
| Rails 7.2 upgrade and CVE remediation (forced) | Blue Shell |
| Archive repacking and manifest publishing, with historical backfill | Lazer Sharks |
| Reduce web-component delivery friction (Next + Flamework monorepo) | Lazer Sharks |
| Rails 8 upgrade, 7.2 EOL August 2026 (forced) | Lazer Sharks |
| JWKS/key-set for Flamework JWT signing, key rotation (forced) | Lazer Sharks |
| Remove legacy ActiveRecord objects in the API | Lazer Sharks |
| Vortex execution plan, release automation, testing (Playwright), Linux dev support | Lazer Sharks |
| Upgrade Vortex libs: Electron 42 and Node 24 (forced) | Lazer Sharks |
| Vortex GitHub backend deprecation (forced) | Lazer Sharks |
| Incremental removal of Flamework pages (derisks moving the mod page to Next) | Orange Box |
| Change 5mods localisation structure off subdomains | Orange Box |
Identified and expected to land on pods other than Platform Engineering. Orange Box does not have the capacity to take the share pointed at it in any reasonable timescale:
| Project | Pod or team |
|---|---|
| Incomplete uploads are cleaned · Remove Flamework-Next proxy on the upload form | Blue Shell |
| Webpack to Vite · Rails monorepo (before monolith) · Rails components into the monolith · React modernisation · caching simplification · Vortex server-naming dependency | Lazer Sharks |
| Subscription flow DX and reliability · pay gem update (forced) | Star Fox |
| Three APIs to one · four permission systems to one · composite-ID migration · GraphQL query cost · bundle download throttling · access control auto-enforcement · download history scaling · CI generated-files handling · dependency injection prototype · Bun-in-Next prototype · AR/ES lookup complexity · search indexes on the v3 API · the Galera question · stack simplification · devspace optimisation · formatting harmonisation · paradigm and structure policies · future-platform prototyping | Unassigned |
Appendix B: key-person dependencies
| Capability | Held by | Where that leaves us |
|---|---|---|
| Dependency resolution, the resolver's core | Two engineers | A single point on the core mechanism of the OS for UGC |
| Malware reverse engineering | One engineer | A single point on Orange Box's North Star |
| Low-level file formats, archives, VFS | Two engineers, both shared or recently moved | Thin cover on the formats the platform sits on |
| Game extension knowledge | Was one engineer, transfer in progress | Unfinished, and now landing on a backend engineer |
| Platform, infrastructure, observability | Three engineers and an architect | Serving four pods, with no permanent lead |
| Vortex client telemetry | Nobody | Install events are wrong, app-side fixes blocked, Growth consumes events nobody builds. Three pillars blocked, no owner |
Appendix C: capacity by pod and department
| Pod | Focus | Tech lead of record | Capacity today |
|---|---|---|---|
| Blue Shell | Creator Experience | Josh Dean (principal) | Carries the largest set of platform migrations alongside its core initiative |
| Lazer Sharks | Player Experience | John Harris (acting) | Carries Vortex release operations, re-ticketed every cycle, and the longest platform list |
| Orange Box | Platform Product, trust and safety | Rory Jennings (also Head of Frontend) | Explicitly limited, malware above all else, one backend engineer |
| Star Fox | Growth | Rory Clark (principal) | Created January 2026, inherited the monetisation experiment programme, holds no app capability |
Backend: thirteen direct reports, interim cover at Head of Department until October. Frontend: the Head of Frontend is also acting tech lead of Orange Box. Platform Engineering: three engineers and an architect, Head acting as lead, serving four pods and owning security posture, developer experience, infrastructure and observability. App: five engineers, reduced by two deliberately while the workload grew, with dedicated game support (unbounded scope, no SLA, no queue) and Linux and SteamOS ownership both unowned. Against the pod template, an optimal pod is eleven roles and fourteen people; no current pod is staffed to it and none is expected to be. Roughly nine of the fourteen seats sit in tech and five outside it, which is why this is a cross-pillar decision.
Key decisions: from many to one
The strategy in one page: every big convergence, its status, and where it stands. Decided means direction is set and work is sequenced. Proposed means it needs the review group. Open means genuinely undecided, with the argument laid out in the Strategy tab.
The decision filter
Six questions to ask before starting any piece of work: a feature, a fix, a refactor, a proposal. If the answers point the wrong way, either don't do it, or raise an enhancement proposal to change the strategy. This page is the whole strategy compressed. If you memorise one tab, memorise this one.
When priorities conflict, don't argue conclusions, argue chains. Write yours out: goal, therefore, therefore, decision point. Two chains side by side usually reveal the actual disagreement in one link, and that link goes to the enhancement proposal process.
Cost model: what slow loops cost us
A live model of what today's friction costs in engineering time, and what fixing it would pay back. Team defaults come from the Delivery Teams sheet (about 30 engineers today, growing towards 40 with the signed-off intake). Friction defaults are calibrated against the Q2 developer survey (April 2026, sixteen developers) and what has landed since: devspace startup is down to about three minutes, CI sharding cut API runs from nineteen to eleven minutes, and review stacks are faster. Those wins are excluded; the model prices only what remains. Every number is a slider: disagree with an assumption, move it, and see what changes. This is the evidence base behind Pillar 2.
Two things this model understates. First, agents: every friction item here throttles AI agents as well as people, and agent hours are far cheaper than the loaded rate, so the true cost of slow loops grows as agent share grows. Second, morale and flow: none of the sliders price what context-switching does to people. Treat the totals as a floor.
Open questions & standing risks
A strategy that hides its open questions gets ignored the first time reality disagrees with it. These are the live ones, each with an owner.
Decisions needed
| Decision | Who decides | Context |
|---|---|---|
| Ratify the embedded platform model pending | Exec | Per the GM's direction, platform work stays inside the feature pods, funded and visible. Exec ratifies the model, the per-pod allocation at planning, the quarterly review and the tripwire (Capacity tab). Growth beyond the signed-off intake is on hold until Q3/Q4 commercial performance is assessed and the hires are ramped. |
| TypeScript endgame proposed | Heads, Principals, Technical Director | Pillar 3, counter-arguments attached. The honest alternative (Rails endgame, TS stays frontend and clients) is stated. What we won't do is leave it undecided while both worlds grow. |
| Runtime for the TS pilot: Bun or Node open | Pilot team + Principals | Decided at the pilot with a real prototype. Bun is the default candidate; Node LTS the fallback. Early code stays free of runtime-specific APIs so this remains a two-way door. A Bun-in-Next prototype is already on the list. |
| Data engines end state open | Heads, Principals, Technical Director | Pillar 4, both positions argued. The next two years are identical either way: Postgres for new work, no dated migration, fix the Flamework coupling. |
| users component: merge or third-party auth open | Investigation (live in Linear) | Investigation covers moving into the monolith, what blocks it, and third-party auth. The roadmap follows the outcome. |
| Doctrine amendment after review | Mari | The doctrine says "all backend into the API" without a language. Once the review group settles Pillar 3, the doctrine records the outcome. |
| Long-term client strategy open | Mari + Product | Vortex is the client, publicly recommitted in the 2026 focus post, with SteamOS support promised. Whether Vortex evolves indefinitely or a successor is ever attempted is deliberately not baked into this document. |
Standing risks
| Risk | Status | Mitigation |
|---|---|---|
| Bus factor of 1 to 2 on Flamework, Vortex internals, malware analysis, file formats | watch | Documentation and pairing while the legacy retires. Retention matters through the whole window. AI amplifies these experts; it does not replace them. A career path for modding and reverse-engineering expertise is an HR action, not an engineering one. |
| "Interim forever": consolidation into Rails becomes the permanent end state by drift rather than decision | watch | The trigger and freeze in Pillar 3, and a review group that has actually ratified or rejected the proposal. Drift is the enemy, not either outcome. |
| Embedded platform work loses to features (the drift this paper documents) | watch | The named guardrails: per-pod allocation visible in cycle planning, quarterly register review owned by the Technical Director, and the tripwire (two consecutive quarters of register growth or forced-work slippage reopens the dedicated-capacity question with evidence). |
| The roadmap is read as promises | open | Sequence over dates, everywhere. The only dated things are decision reviews. Anyone quoting a delivery quarter from this document is misquoting it. |
What input is wanted, from whom
Heads of Department: does the sequence match your capacity reality, and what would you cut or reorder? Principal Engineers: attack Pillar 3 and Pillar 4 on technical merits, and the Cost Model's assumptions with your own numbers. Technical Director: does the whole thing cohere, and where does it conflict with the company strategy's pillars? Housekeeping while we're here: the published architecture timeline badges the Nexus Mods App as TypeScript (it was .NET) and still shows passed provisional dates for uploads and filestats; both should be corrected so the published pages stay credible.