TL;DR: At RAQTS I stepped in as CTO during a critical phase to lead a sports-tech platform that connects players and facilities, and the work spanned three runtimes at once: a Unity interactive layer called Lumo, React Native mobile apps, and a Next.js web portal, all tied together by live leaderboards and shipped through the App Store and Play Console. This is what it takes to join a project mid-flight, hold one product together across Unity, mobile and web, and make real-time scores that people trust show up on every screen at the same time.
Most engineering stories start at day one with a clean repo. This one did not. I came into RAQTS when the platform already existed, already had users depending on it, and needed technical leadership through a phase where the stakes were high and there was no room to stop and rebuild. That changes the job. You are not designing from scratch, you are steadying something in motion and shipping while it runs.
Joining a project in a critical phase
Stepping in as a CTO mid-build is a different discipline from founding one. The first task is not to write code, it is to understand what already exists well enough to not break it. A live sports-tech platform has real players and real facilities on it, so the cost of a careless change is not a failed test, it is a facility that cannot run its session tonight.
So the early work was reading, not writing: how the Unity layer talked to the backend, where the mobile apps got their data, what the web portal was actually responsible for, and where the seams between them were fragile. Only once that map was in my head could I lead confidently. The instinct here is the same one I wrote about in my freelance lessons piece: move fast, but earn the right to move fast by understanding the ground first.
A critical phase also means triage. Not everything can be fixed at once, and pretending otherwise is how you stall. The job was to find the few things that most decided whether the platform stayed trustworthy, the release pipeline and the live data, and put my weight there first.
One product, three runtimes
The hardest thing about RAQTS technically was that it was one product living in three very different worlds at the same time. A player might interact with the Unity Lumo experience, check their standing on the mobile app, and a facility might manage everything from the web portal. To the user it is one system. Underneath it is Unity, React Native and Next.js, three stacks with three release cadences and three sets of assumptions.
The discipline that keeps a split like this from fracturing is the same one I learned building a cross-platform C# SDK at Geonode: share the truth, never the platform. There has to be one authoritative source of what a score is, what a session is, what a leaderboard says, and each runtime is just a different window onto that same truth. The moment two clients start disagreeing about the state of the world, the product feels broken even if every individual app is technically working.
The Lumo interactive layer in Unity
Lumo is the interactive Unity platform, and Unity is where I have spent more than five years, from AR systems to game work, so this was familiar ground. But an interactive layer inside a larger product is not a standalone game. It cannot own its own version of the truth and it cannot assume it is the only thing running. It has to render the experience beautifully while treating the backend as the authority for anything that counts, especially scores that will show up elsewhere a second later.
That constraint, a rich client that defers to a shared source of truth, is exactly the mindset I carried in from building AR for firefighters at ARCortex. A compelling visual layer that quietly lies about the underlying data is worse than a plain one that is always honest. Lumo had to be both compelling and honest, and honesty meant never being the place where a score was invented.
The mobile apps and the web portal
The React Native apps and the Next.js portal serve different people. Players live on mobile: quick checks, their own standing, the moment-to-moment. Facilities live on the web portal: management, oversight, the wider view. Building both means resisting the temptation to make one a shrunken copy of the other. A facility operator's needs are not a player's needs scaled down, they are a different job.
What they share is the data layer and the outcome model. A leaderboard position is the same object whether a player sees it on their phone or a facility sees it on a dashboard, which keeps the reporting sane. I made the same argument one layer up in voice and chat agents converging into one pipeline: let the front doors differ, keep the building behind them shared.
Live leaderboards are a real-time systems problem
The feature that sounds simple and is not is the live leaderboard. A leaderboard is easy to build if it can be a few minutes stale. It becomes a real engineering problem the moment it has to be live, because now every client has to converge on the same ordering, fast, while scores are still changing.
The hard parts are the ones that do not show up in a demo:
- Everyone has to agree. A player looking at their phone and a facility looking at the portal must see the same standings within moments of each other. A leaderboard that shows two different orders on two screens destroys trust instantly, because the whole point of a leaderboard is that it is the shared truth.
- It has to survive a bad connection. Mobile networks drop. A client that misses an update cannot be left showing a frozen, wrong board forever. It has to reconcile when it reconnects and catch up cleanly, the same design-for-being-interrupted instinct I leaned on for background networking that has to survive being suspended.
- The write path is the truth, the read path is fast. Scores get written in one place with authority, and read in many places quickly. Keeping that separation clean is what lets the board be both correct and responsive instead of trading one for the other.
The rule I kept was that the backend owns the ordering, always. No client ever computes the leaderboard from its own partial view and shows that as fact. Clients render what the authority tells them and reconcile toward it. That is slower to build than letting each app do its own math, but it is the only way three runtimes ever agree on who is winning.
Shipping to the App Store and Play Console
The unglamorous half of a mobile product is release management, and on a live platform it is where a lot of the real risk sits. I managed App Store and Play Console releases for RAQTS, and anyone who has done it knows the calendar is not yours. Review times, store policies, signing, staged rollouts and the fact that a shipped mobile build cannot be hot-fixed the way a web deploy can all shape how you work.
That last point matters most. A Next.js portal can be fixed and redeployed in minutes. A React Native app in the wrong state is on users' phones until the next review clears. So the mobile release bar has to be higher, the testing more paranoid, and the backend has to be forgiving of older app versions still in the wild, because not everyone updates the day you ship. Designing the server to stay compatible with clients you no longer control is a permanent tax of shipping to app stores, and forgetting it is how a good release becomes an outage for the slow updaters.
This is the same lesson that a cross-platform SDK taught me in a different shape: the software that lives on someone else's device, out of your reach, has to be the most carefully shipped of all, because you cannot take it back.
What stepping in as CTO taught me
RAQTS sharpened a set of instincts I now bring to every leadership engagement, and they generalize well beyond sports tech.
- Steady before you change. Joining mid-flight means understanding the moving system before touching it. Triage the few things that decide trust and start there.
- One truth, many windows. Unity, mobile and web are just views. The score, the session, the leaderboard live in one authoritative place, and every client defers to it.
- Live is a systems problem, not a UI one. A real-time leaderboard is about convergence, reconnection and a clean write-versus-read split, not about the pixels.
- Respect the store cadence. Mobile builds you cannot hot-fix demand a higher bar and a backend that stays kind to old versions.
The through line from Unity games to AR platforms to AI agents, an arc I have been on for years now, is that the tools change and the judgement does not. Knowing what a product cannot afford to get wrong, and building the boundary around that first, is the same skill whether it is a firefighter's overlay, a background SDK, a voice agent, or a live leaderboard that a room full of players is watching in real time.
I lead engineering as a fractional CTO and build cross-platform products, from Unity and mobile to real-time web systems and AI agents, for teams that need the hard parts done right. If that is you, more about my background here, or book a call.