Becoming a CTO

26 September 2026

From making games to leading a tech platform for 12 years.

Background

In 2014, my games company, Melee Studios, was acquired by Hyperspace (formerly LearnBrite), and I joined the company as CTO. It was really a fancy title for an actual Principal Engineer.

The company had just been founded, and it had good potential, as it was focused on building browser-based 3D games and simulations for education, training and corporate use.

Our first project was a training simulation for Curtin University called Virtual Home Visit.

The birth of a platform

I chose Three.js as the 3D engine for the project since I had some experience with web technologies. For the environments, I hired a 3D artist to build the models. We did many tests to ensure the game would run smoothly across different browsers. I already had plenty of experience working with artists and integrating assets, so that part was easy.

The first big challenge (and one that would follow me throughout my time at the company) was 3D avatars. The company owned an old consumer virtual world that included a large avatar content library. I made a pipeline to convert and import around 14,000 assets into our platform, and created an avatar system with layered animations.

I built a simple backend in PHP/MySQL to handle user accounts. Soon after, I designed a gamification engine to track user progress and manage tasks and achievements.

We acquired Urban Brain Studios in 2015, and I integrated its dialogue editor, ChatMapper, into our platform, so authors could design their character interactions.

As an accessibility feature, we added ResponsiveVoice, a text-to-speech library I had created as a weekend experiment, to our platform. Our characters could now also speak in 50+ languages.

Authoring came right after. Our goal was to create a platform where clients could create and run their own experiences without writing code. I made 3D scenes editable directly in the browser. This meant creating my own physics engine, adding roles and permissions, an API for saving scene layouts and a repository of 3D items.

The platform went multi-user. I created a protocol for signalling and supported around 250 users in a scene. More about this in Multi-user & real-time systems.

A new Virtual Reality wave came. At the time, doing VR on the web was mostly experimental. Specs were just starting to emerge and browser support was very limited.

Those were a few years of following developments closely and adapting our code rapidly to keep up with the changes. I had to work very hard to stay current while adding new features to the platform and supporting projects already in production.

Scaling up

The pandemic hit, and virtual meetings exploded in usage.

In 2020 Hyperspace had a sudden surge in demand, and we had to scale accordingly. We hired new team members and had multi-year contracts with big corporations, planning events for large audiences.

We added audio and video conferencing capabilities to the platform through WebRTC, integrating services like Twilio, Vonage, Ably and Zoom. Presenters could share their screens, audio and video with participants in real time.

250 wasn't enough. That's how many users our platform could initially handle at the same time. I worked closely with our infrastructure expert to design a new scalable architecture that would support the numbers we were looking at. This ended up being a multi-year effort that involved multiple iterations, countless hours of meetings, extensive testing and a few panic attacks along the way.

We adapted a handful of different components to Kubernetes and moved the databases to a distributed architecture. Our production cluster on GKE was now capable of scaling horizontally on demand, and we could handle 16,000 concurrent participants in one event. More about this in Backend & infrastructure.

On the frontend, I got 2,000 avatars rendering in one scene. More about this in Real-time 3D on the web.

Scaling also meant changing how the platform behaved logically. We had to rethink user interactions, add moderation tools, introduce queues, and provide fallback mechanisms for nearly every operation.

Managing others

As the team grew, my focus shifted towards management and architecture. Having other team members building projects with the platform and contributing to its codebase meant I had to create better documentation, guidelines and workflows. We adopted JIRA and Confluence for project management and documentation.

I started having regular meetings with the dev team while also taking part in strategy and roadmap planning with the leadership team. I also drafted JIRA issues, gave developers direction on solving bugs and reviewed their PRs.

I was managing 8 people. The team included 3 developers, 2 3D artists, 2 QA engineers and one instructional designer. Coordinating the work while supporting each member individually was challenging, but I started to really love it.

There were some difficult moments where I learned to manage conflict and pressure. We had more than one high-stakes event where things didn't go the way we planned. I managed stressful meetings with devs while trying to recover from critical failures during events, and difficult conversations with clients afterwards where I had to present reports and repair damage.

One of the hardest situations happened during a product launch event: a treasure hunt with cash prizes for completing quests. Our gamification monitoring started to report too many interactions from thousands of participants. Our job queue simply couldn't handle the number of jobs, and many interactions went untracked. The organisers had to pause the treasure hunt several times. It took us several hours to identify the cause, and by the time we fixed it, the damage was already done. Thousands of interactions were not recorded, rewards couldn't be verified and participants complained, as they had been promised prizes that couldn't be correctly awarded. We lost that client. It was a hard lesson on the importance of load testing and rehearsals.

These situations made me realise how important it is to establish a good working environment and hire people who are not only capable, but also honest and genuinely good. That really pays off in hard situations where a team needs to join efforts to fix a problem, help each other and take ownership.

Modernising

As our own plans, market opportunities and client requests kept adding new requirements to our roadmap, I had to constantly balance priorities and decide where to invest our time. We had a long list of bugs to fix with various levels of priority, new features to implement, a growing, haunting technical debt and some long-obsolete technologies that we somehow kept supporting. I learned that there isn't one perfect answer to these challenges. I also discovered the value of a flexible, adaptable mindset, and of good engineers who would support and challenge me along the way.

In 2023 we started transitioning the main frontend codebase from vanilla JS to TypeScript, and the UI from Bootstrap to React. It was a multi-year process, and we had to carefully plan it in phases.

Meanwhile, ResponsiveVoice, the text-to-speech library I created, was hitting 90M+ monthly users, and we had hired support agents to handle the incoming requests. That same year, it spun out as a standalone company, where I stayed on as an advisor and shareholder.

In 2024 we acquired Glue, a Finnish VR workplace company. I took part in the technical due diligence, the handover and the integration.

The rise of AI

Before ChatGPT existed, we were already using AI-driven conversational characters. More about this (and agentic development) in AI and LLM.

Our development team quickly adopted Copilot and later Claude into our workflows. I spent a lot of time creating and testing guardrails for our agents.

The rise of AI allowed us to ship faster, but I had to work very hard to keep everything under control. That meant writing very detailed and thought-out specs, and spending hours planning features and designing architecture.

Somebody AI

In 2025 we were planning to release AI-driven soft-skills training and assessment experiences on our platform. As we were creating them, we ended up envisioning a completely new product for conversational agents, called Somebody AI: realistic 3D avatars that users can talk to in real time.

Designing the platform from zero gave me the freedom to work without restrictions on technologies, requirements or technical debt, which was very refreshing and exciting. I was able to spend time getting up to date with both frontend and backend technologies.

As we finished and released the first version of the product, I decided to make some changes in my professional career. That moment felt like I had finished a chapter, and I was excited to try something new.

Final notes

Staying for 12 years in the same company is rare nowadays. I believe that, amongst other things, it's a testament to how good the relationship with my peers was.

I faced many technical, organisational and personal challenges, learned to balance priorities and compromises, and grew as an engineer and as a leader.

Looking back, the parts I enjoyed the most were designing architecture and supporting the people building it with me. That's what I'm looking for in the next step of my career: a hands-on leadership role where I can bring my years of experience both to the developers and to management.

This article is the second part of a two-part series on my career. The first part is My career in videogames.

Projects in this article

View as Markdown