Full-Stack Isn't a Stack — It's a Mindset

People want a one-word answer to "what do you work in?" — React dev, .NET dev, Python dev. I've never been able to give one, and I've stopped apologising for it. The work I'm proudest of crossed every layer: a Flutter app talking to a serverless backend, a Next.js portal over a Postgres model, infrastructure-as-code holding the whole thing up.

Stacks are tools, not identities

I write production code in React, Next.js, Node and TypeScript, Python, Flutter, and yes C# and .NET. None of those is "me." They're tools I reach for when the problem calls for them. Tying your identity to a framework is how you end up solving every problem in that framework's shape, whether it fits or not.

The full-stack advantage is seeing the seams

Most bugs and most delays live at the boundaries — between the app and the API, the API and the database, the code and the infrastructure. If you only own one side, those seams are someone else's problem and they fall through the gap. Owning the whole path means I see the seam before it tears.

Still hands-on, on purpose

I lead teams, and I still ship code every week. That's a deliberate choice, not nostalgia. A leader who's stopped touching the work loses the instinct for what's actually hard, starts trusting estimates they can't sanity-check, and slowly becomes the person decisions route around. Staying in the code keeps the leadership honest.

What this means if you're hiring me

You're not getting a specialist who needs the rest of the team to fill the gaps around them. You're getting someone who can pick up whatever your stack is, ship in it, and lead others doing the same — because the mindset transfers even when the syntax doesn't.