When I applied to CHECK24, I reached for Zod to validate the input in the coding challenge. It caught someone’s eye. I later learned that my future team lead had noticed the type-safety habit and argued for me. I was still at university, and I ended up on his team building insurance-comparison flows in React, TypeScript, and PHP/Symfony.
That was not where it started. My first professional software job came at nineteen, at homevoice, building property-management software with React and Spring Boot. Around and between studies I also freelanced, building websites for artists and small businesses, which taught me how to explain technical possibilities and constraints clearly to clients and collaborators without a technical background. I left CHECK24 with a good review and an open door to return, then moved to BuildlinX, where I now carry architecture responsibility across selected product areas: from the web frontend through the backend to the edge systems, in TypeScript and Go.
In my own projects, I spend a lot of time exploring the TypeScript ecosystem. I like wiring a system so that a change to the database schema shows up as a type error in the frontend, where the mistake surfaces at compile time instead of on someone’s screen. Lately that means leaning on Effect, which I use to structure modular, composable TypeScript applications; typed errors and dependency injection are part of that, not the whole point. I think it’s currently the strongest foundation TypeScript has for that kind of architecture, though I try not to be dogmatic about it: I’m still finding the line between where it earns its cost and where it’s overkill.
I use AI agents heavily for investigation, drafting, and implementation, mostly through Codex, while owning architecture, review, and verification. Generated work has to meet the same standards for tests, types, and maintainability as any other change. The tools keep getting better, and I want to keep getting better at directing and checking them.
