In March 2025, I started building a replacement for the spreadsheet I used to manage my video game collection.
I had maintained that spreadsheet for ten years. It contained all the small, particular details that matter to a collector: editions, platforms, condition, box contents, purchase history and the inevitable duplicates. Replacing it was not a hypothetical product exercise. The new system had to be good enough for me to entrust it with data I genuinely cared about.
The most significant milestone came when I stopped updating the spreadsheet and said: this is production for me now.
The project eventually became The Game Project, which I soft-launched publicly this month, in September 2026. It gave me the collection and backlog tool I wanted, but its value extended well beyond that original objective. Over 18 months it became a laboratory for technologies, engineering practices and product decisions that I would not have encountered in the same way through my day job alone.
It reinforced something I have come to believe strongly: side projects aren’t a distraction from technical leadership. For me, they are an important part of remaining relevant, informed and pragmatic.
Side Projects Create Different Constraints
Large organisations have broad context. Adopting an unproven technology, particularly one without a critical mass of internal expertise, is not a decision that should be made by one person on a whim.
There are security implications, regulatory requirements, existing platforms, commercial relationships, operating models and teams who will inherit whatever gets built. Responsible decision-making requires consultation and evidence. That takes time, and risk avoidance can slow down innovation. Sometimes that is frustrating; sometimes it is exactly what the organisation needs.
A personal project changes those dynamics. I can choose an unfamiliar language, replace a tool or abandon an approach without building organisational consensus first. I fully own the risk, the consequences and the learning curve.
But personal projects are not free of constraints. They substitute different ones.
A workplace may have a substantial cloud budget and value time-to-market above infrastructure efficiency. I am unwilling to spend $1,000 or more per month running a personal project. I have limited time, nobody on call and no specialist teams to absorb complexity. Those constraints force a different kind of innovation.
Moving between the two environments is useful because neither produces universally correct answers. One teaches you to operate within organisational complexity; the other lets you test your assumptions with fewer barriers and a much more personal budget.
Learning Flows Back Into Work
The Game Project was never professional homework wearing a hobby’s clothes. I wanted to build a cool thing. I love video games, I enjoy building systems, and the product solved a real problem for me.
It was built independently, using my own time and resources. However value flowed back into my professional work with the experience and judgment I developed by solving real problems for myself.
Before starting, I had little experience building backend services in TypeScript. I wanted to keep the frontend and backend in one language, so I accepted the learning curve and built the API in Node.js and TypeScript. Six months later, I used that experience to build a proof of concept at work for a strategically important middleware component. I would not have had the confidence, knowledge or practical experience to take that leap without the earlier learning.
The proof of concept was developed into a production system over the following months and became a highly successful project, enabling important strategic partnerships. That is a direct line from a personal technology bet to a valuable workplace outcome.
My early experience with agentic development followed a similar path. I had spent enough time using the tools on real, complicated work to understand both their capability and their failure modes before our broader internal rollout began. That allowed me to contribute to business direction and run engineering enablement from an authentic, practical position. I wasn’t repeating a vendor demonstration; I could explain what worked, what didn’t, and how engineering practices needed to adapt.
Learning Agentic Development by Doing It
The development of The Game Project overlapped with a remarkable 18 months of change in coding tools.
I began with Cursor. It was an approachable entry point: a familiar IDE with something like a “code completion plus” experience. The interaction remained close to conventional development, with AI accelerating work inside an established workflow.
I moved to Claude Code when the stronger Sonnet models arrived. The initial results were mixed. Getting consistently useful outcomes required changing how I worked, not merely changing the model. I developed the problem discovery, solution discovery and implementation phases I have previously written about in Agentic Coding: Workflow Over Tools.
As the models improved, that agentic workflow became my default. My role moved further away from manually producing every line and further towards defining the problem, supplying the right context, reviewing the proposed approach and verifying the result.
More recently I moved much of the work to Codex. That is another experiment: partly motivated by the cost and latency I had experienced elsewhere, and partly by wanting firsthand experience of a different tool and model family. I have been impressed by the cost-to-performance of the Sol model, even while Claude Code remains the more mature harness in some respects.
The individual tool verdict is less important than the progression. I could not have developed an informed view of agentic engineering by reading release notes or watching polished demonstrations. The useful knowledge came from using several generations of these tools against the same long-lived codebase - and being accountable for what they produced.
Cloud Architecture Meets a Personal Credit Card
Infrastructure produced another valuable collision between familiar patterns and different constraints.
The conventional architecture available to me was obvious: an Aurora database, resilient compute across ECS or EKS, ElastiCache and the associated networking and operational services. I knew how to build that environment, but it establishes a significant cost floor before the application has any users. At the lower-cost end, it also buys surprisingly little capacity or performance.
The technically familiar answer was economically wrong for the project.
Instead, I bought lower-level compute capacity and accepted more responsibility for operating it. Dokku provides a lightweight platform layer for the API, workers, PostgreSQL, Redis and other self-hosted components. It gives me a Heroku-like deployment model without requiring a platform that costs more than the application can justify.
I still use managed services where their economics are compelling. AWS provides SES and SNS for email, S3 for object storage, and CloudFront for image delivery and transformation. Cloudflare handles static sites, CDN, DNS and email routing. AWS resources are defined using CDK, giving me repeatable infrastructure and environment isolation without pretending everything needs to live in AWS.
This is not an argument that self-hosting is inherently better. I traded money for operational effort, which would be the wrong trade in many organisational settings. It was the right trade under this project’s constraints.
More importantly, making that trade myself improved my understanding of both sides. Managed platforms do not merely charge for compute; they charge for reducing operating responsibility. Whether that premium is worthwhile depends on the product, team, risk and stage.
LLM Features Are Product Decisions
The Game Project also gave me room to integrate language models into the product itself, across several data-processing use cases.
That experience quickly dismantled the idea that selecting a model is a one-dimensional leaderboard exercise. The best choice depends on the job.
Smart Import, for example, helps a new user map and normalise years of collection data. It sits directly in the onboarding journey. Latency matters because every additional wait creates another opportunity for somebody to abandon the process. Groq carries a cost premium, but its excellent inference speed can be worth paying for in that context.
The economics are different for inbound game-data queues. That processing happens in the background, so saving a few seconds creates little user value. Cost and task effectiveness should dominate model selection there.
I initially used DeepInfra extensively. It is a solid provider, but occasional outages and capacity limitations eventually pushed me towards OpenRouter. OpenRouter costs a little more, but broader model availability and the ability to route around provider issues have operational value.
The result is not a single “best” model. I benchmark models for each use case and choose the best cost-to-performance fit for that task. The system uses a mixture of GPT mini, GLM, Qwen and Llama models. Quality, latency, cost, availability and output consistency all become product concerns once an LLM is inside a user journey rather than sitting in a demo.
Again, the important learning came from consequence. I paid the invoices, experienced the outages, measured the latency and watched the feature experience change. That produces a different kind of understanding from comparing published benchmark scores.
Staying Close Enough to See the Complexity
Technical leadership inevitably creates distance from implementation. More time goes into organisational design, strategy, communication, investment decisions and helping teams succeed. That is part of the role.
But distance carries a risk: it becomes easy to forget how much subtle complexity hides beneath things that sound simple.
“Let users import a spreadsheet.” “Add authentication.” “Use an LLM to classify the data.” “Put it in the cloud.” Each can fit into a sentence. Each contains edge cases, trade-offs and failure modes that only become obvious as you build and operate it.
One of my favourite parts of engineering is the moment when an apparently simple problem reveals its hidden complexity, I finally understand it, and can collapse that understanding back into a genuinely simple solution. Side projects gave me those moments repeatedly.
They also reminded me what implementation actually asks of engineering teams. Staying hands-on can mean writing production code, retaining enough architectural fluency to challenge a proposal, understanding modern delivery friction firsthand, or keeping your intuition calibrated against what technology can really do. The emphasis will vary with personality and leadership style, but all of those forms remain relevant.
This matters more than ever in an agentic engineering world. Producing plausible code is becoming easier and faster. Understanding the hidden complexity, creating simplicity and recognising when a plausible solution is wrong remain human responsibilities. A leader who loses contact with the details risks forming opinions from plausible abstractions, marketing copy and vendor claims instead of engineering reality.
Finishing Changes What You Learn
The Game Project became substantial, but during the same period I started other, much smaller experiments. Some shipped and some did not. All taught me something different.
Finishing is still worth pursuing. A working prototype teaches you about construction; a system you depend on teaches you about reliability, migration, maintenance and trust. Declaring The Game Project “production for me” exposed lessons I could never have found in another abandoned proof of concept.
More than anything, the project reminded me that I still love building things. That is why I entered this profession and why I have stayed in it. Genuine curiosity carried me through the difficult parts and every solved problem created the energy to tackle the next one.
Side projects aren’t separate from my growth as a technology leader. They are where I rebuild the firsthand experience that keeps my leadership relevant, informed and pragmatic - and where I rediscover the fun of turning an idea into something real.
The Game Project has been live since September 2026. If you collect video games, have a backlog that is getting out of control, or are simply curious to see what all this experimentation produced, take a look at The Game Project.