About Me

I'm a backend-leaning full stack developer who spent the last four years building production systems at M8Y1 Gaming a multi-client software studio where I was the platform engineer across concurrent web and mobile projects. Most of my days were inside NestJS microservices, Docker containers, and PostgreSQL schemas, with a fair amount of time spent on DevOps automation: CI/CD pipelines, Makefile scripts, NATS message brokers, and Redis caching layers.

I moved to Melbourne in mid-2025 to complete a Master of Information Technology at La Trobe University, where I'm splitting time between coursework AI, deep learning, algorithms and side builds. The coursework has pulled me toward the ML side of engineering in a way that professional work didn't, which I'm actively exploring through FitForge an AI fashion platform using SMPL-X body modelling and AR try-on built with Team Nexus.

My engineering philosophy: systems should fail loudly and predictably. I'd rather a hard error at startup than a silent wrong answer at runtime. This shows up in how I approach schema design (explicit constraints over application-level validation), API design (explicit error codes over generic 500s), and multi-tenant architecture (schema-level isolation over shared-table row filtering).

What I'm working on and thinking about right now:

• Master of IT coursework at La Trobe AI, deep learning, state-space search algorithms
• FitForge SMPL-X body modelling and AR try-on for personalized fashion (Team Nexus)
• Exploring agentic AI workflow design and structured output pipelines
• Open to full stack and platform engineering roles in Melbourne or remote

I prefer small, focused pull requests over large diffs. I write code that makes wrong states unrepresentable where possible TypeScript discriminated unions, PostgreSQL constraints, NestJS guard composition so that errors surface at compile time or startup rather than in production. I spend more time on interfaces between components than on component internals, because that's where most bugs actually live.

In a team context: I ask clarifying questions early, I'd rather discuss the architecture before writing the first line, and I write commit messages that explain why rather than what (the diff already shows what). I'm most useful when I understand the business context behind a technical requirement the tradeoffs become clearer.

When I'm not at a keyboard, I'm usually testing a new paneer recipe, reading about the ASX, or exploring Melbourne one suburb at a time. I find financial markets interesting for the same reason I find distributed systems interesting they're complex adaptive systems where local decisions produce emergent global behaviour that surprises everyone, including the participants.