Solve first, then hand it over
When I joined, the team had no tests, linter, formatter, or CI, none of the basics of modern application development, so it was hard to notice when a change broke existing features. I introduced automated tests and CI, and planned and taught a workshop for members who had never written tests. Bugs are now caught earlier, and checking that nothing else broke is much easier. Questions about the game's specifications also kept going to the few people who knew them, and the documents were too scattered to search. So I built an internal AI chat on Amazon Bedrock that answers questions from the specifications, designs, source code, and master data. People outside engineering use it too.
Choose technology for a reason
The game server is written in .NET (C#), but the admin console alone was built with Next.js, and almost no one in the company could work with Next.js or JavaScript, so maintaining it cost far too much. I rewrote it in Blazor, in the same C# as the game server, so the whole team can maintain it. Database migrations used to be automated only up to generating the diff SQL; running it was manual. I moved to Atlas, which detects and applies the diff automatically. For image thumbnails, instead of generating every size in advance, CloudFront calls Lambda to create one only when it is not in the cache, so no storage or processing is spent on images nobody views.
Measure, then improve
When someone said the game was slow, nobody could show objectively where or how slow; we relied on gut feeling. I introduced APM so the time spent in each operation is measured, and we check it regularly to show with numbers that nothing has gotten slower. For load testing, I organized a four-person reading group on a book about load testing on AWS so the whole team shared the same knowledge, and I reviewed the test plan and scenarios. At ISUCON2026, too, I improved the application step by step based on measurements.