From C# desktop apps to mobile games: teaching, support and AI-assisted work

I started out writing desktop apps in C# with MS Access databases. After that I taught IT at a vocational high school for a term and a half, then joined NarPOS, a point-of-sale software company, as an intern and left as the technical support team lead. Today I build mobile games in React Native and websites in Next.js, and most of that work happens alongside AI coding agents.

On paper the path zigzags. Moving from development into support, or from a classroom into industry, can look like a detour. Each step taught me something I still use, and a lot of how I work now traces back to them.

First programs: forms, tables, reports

I studied in the IT department of a vocational high school and then did an associate degree in computer programming. Most of what I built in those years had the same skeleton: a database, a few tables, screens for adding, deleting and searching records, and a report.

A car dealership app tracked vehicle sales and customer records along with the lot's stock. I built it twice, and for V2 I redesigned the interface from scratch because the first one was hard to use. Pharmacy and library tracking apps ran on MS Access. The stock tracking system used MS SQL Server, handled stock movements and low-stock alerts, and had reporting queries that joined several tables.

I also wrote a Flappy Bird clone in Windows Forms.

It was my first game. Collision detection, scoring and the game loop were all written from scratch. Years later, writing the tower simulation for Stack the World, I ran into the same question I first hit in that small project: if the frame rate changes, does the game speed change with it? This time the answer was a fixed-step loop, but I'd met the problem long before.

What teaching taught me

As an IT teacher I taught C# programming, SQL and database management, robotics with mBlock5 and Arduino, and visual design.

Teaching shows you exactly where your understanding ends. Skip a step while explaining a JOIN or a loop on the board and someone in the room notices immediately.

That's where I learned to break a topic into pieces that each make sense on their own. It maps directly onto how I hand work to an AI agent now: a task with clear boundaries and a result I can check. Give a vague task to an agent or a student and they'll both fill the gaps their own way.

NarPOS: from intern to team lead

I spent a little over two years at NarPOS and held four different roles.

As an intern I worked on maintaining and testing desktop applications and on Android and iOS version updates, and I took part in Git workflows and code reviews. As a developer I wrote multi-layer automation software in C#, designed and tuned SQL Server databases, and built Angular single-page apps backed by REST services in C# Web API.

Then I moved to the support side. As a technical support specialist I handled tickets and planning in Jira, POS installs and updates, database work and system integrations. From September 2025 to July 2026 I led the technical support team, which meant third-level support, log analysis, integration setup, TCP/IP and DNS configuration, and API validation with Postman.

Going from developer to support sounds like a sideways move. What it gave me was a view of how code breaks in the field. Users almost always see a generic error, and the actual reason is sitting in a log somewhere. Checking the log first became a habit there.

That habit paid off later. During Stack the World's closed test, Google sign-in failed for everyone who installed from Play, showing only "couldn't connect". The screen said nothing useful, while logcat said plainly that the app wasn't registered for OAuth. The cause was a wrong signing fingerprint, and adding the right one fixed it on the spot.

Moving to AI-assisted development

These days I work with Claude Code and Codex, often running several agents at once. One agent can be working on the game's audio while another runs performance measurements, and I review each result before deciding what goes into the main branch. My own job has shifted toward describing the work, checking what comes back, and making the calls.

I've tied this to a few rules. Every piece of work starts with a design document; Stack the World has separate design and plan files for its language system, its performance work and its store process. Only one agent writes code in a repository at a time, and the others read. Parallel work runs in separate git worktrees. I learned why while running agents side by side: when two of them edit the same config file, one can quietly overwrite the other's change.

I haven't left C# behind either. This month I built a B2B ordering system on .NET 9 Web API, EF Core and SQL Server, with product search on Elasticsearch and Redis. TypeScript's type system and syntax are close to C#'s; Anders Hejlsberg designed both languages.

Tests are the gate. Stack the World has more than 7,000 Jest tests, and nothing lands on the main branch until tsc is clean and the whole suite passes. When an agent reports that something is done, I look at the test output before I believe it.

Measurement works the same way. An agent's idea can sound reasonable and still make things worse once you measure it; converting icons to images was one of those. I run comparisons by interleaving the two configurations over several rounds, because a difference that shows up in only a few runs often turns out to be noise.

Practical lessons from the path so far

A few things I'd pass on to someone on a similar road:

• Don't dismiss small CRUD projects. A data model and a search screen are the first version of the problem I later solved with Elasticsearch in that B2B system.
• Learn to read logs early. The message a user sees rarely tells you the real cause.
• Try explaining a topic to someone else. The place where you get stuck explaining it is usually the place you only half understand, and handing work to an agent uses the same skill.
• Accept AI output on the strength of tests and measurements. Code that was written fast hasn't proven anything by being fast.
• Keep the jobs that look like side steps on your CV. Support and teaching show you real failures and how people actually learn, up close.

Right now Stack the World is waiting on store approvals and the next game is waiting its turn. What I enjoy most hasn't changed since that first Flappy Bird clone: watching something I built run on a screen.