Behind WebCoreX

I'm a developer who learns fast and goes deep. When a project needs something I haven't used before — a new framework, an unfamiliar protocol, a legacy codebase nobody wants to touch — I don't stop at getting it to run. I take the time to understand how it really works. That's what lets me choose the right tool, use it well, and fix problems at their root instead of patching symptoms.

That habit has taken me well beyond a single stack. I've connected WPF software to PLCs and weighbridge hardware in real time, then carried the same system to the web with Blazor. I've built a real estate platform in Python and Django, modernised legacy WebForms without breaking what already worked, and kept a multi-store pharmacy chain running smoothly across VPNs, point-of-sale sync and monitoring. My home is the Microsoft ecosystem — .NET, Blazor, ASP.NET Core — but the approach is the same everywhere: understand first, then build.

Good software starts with people, not code. I talk to the ones who will actually use it — the cashier, the manager, the support team — to find the real problem behind the request. Then I work in small, testable steps, so you see something working early and we shape it together, instead of waiting months for a big reveal.

I build for the long run. I want what I deliver to keep making your work easier years from now, and I want to be the partner you can still call after launch. When the people using the software are better off, the business follows — that's the measure of success I care about.

My path into software wasn't the usual one. Before development, I studied Sociology, Psychology and Criminology and worked in public service in law enforcement. Those years taught me how people think, decide and work under pressure — and that understanding still shapes every workflow and interface I design.