Technology

I use a wide range of technologies, but the starting point is never the tool.

It’s the problem.

The right stack depends on the system you’re building, the constraints around it, the team that has to maintain it, and the tradeoffs that actually matter. I care less about chasing the perfect technology and more about choosing tools that fit the business problem, hold up under pressure, and give teams room to build well over time.

That said, there are a few areas and technologies I keep coming back to.

Distributed Systems and Event-Driven Architecture

A lot of my background is in distributed systems, real-time software, and event-driven architecture. I’m especially interested in systems that need to stay responsive, resilient, and understandable as scale, complexity, and organizational pressure grow.

Apache Kafka is a big part of that world for me. I’ve used it heavily for streaming systems, asynchronous workflows, event-driven integration, and architectures where decoupling, durability, and real-time data movement matter. I’m drawn to the kinds of systems where events become a core design primitive rather than just an implementation detail.

More broadly, I think event-driven architecture is one of the most powerful patterns in modern software when used well. It can enable flexible, scalable systems, but it also introduces tradeoffs around complexity, observability, consistency, and ownership that need to be handled deliberately.

Software Architecture and System Design

I’m deeply interested in software architecture as both a technical discipline and a decision-making discipline. Good architecture is not just about selecting patterns, frameworks, or infrastructure. It is about shaping systems so they remain understandable, adaptable, and operationally sane as they grow.

That includes boundaries, service design, communication patterns, data ownership, failure handling, and the tradeoffs between speed, complexity, and long-term coherence. I’m especially drawn to systems where architecture has to do real work: platforms with multiple moving parts, domains with real operational pressure, and organizations where poor system design becomes expensive quickly.

I’m also influenced by approaches like Domain-Driven Design when the problem space justifies them, especially in systems where domain complexity, boundaries, and language matter as much as implementation details.

I care a lot about software that is well-shaped, not just functional.

Backend and Platform Engineering

On the backend, I tend to work in ecosystems that support strong architecture, high performance, and long-term maintainability.

I’ve spent significant time with Java and Spring Boot, especially in backend systems that need to be reliable, maintainable, and built to scale. I’m also interested in tools like Vert.x for event-driven and high-concurrency use cases.

I also work extensively in TypeScript and enjoy building backend systems with frameworks like NestJS, particularly when modular design, strong developer experience, and clean service boundaries matter.

What matters most to me on the backend is not just the framework, but the shape of the system: clear abstractions, operational simplicity, maintainable code, and software that can evolve without becoming brittle.

Frontend and Product Development

I enjoy working across the stack, not just at the service layer. On the frontend, I typically work with React and Next.js to build modern web applications with a strong focus on clarity, performance, and usability.

I like frontend systems that are clean, intentional, and well-connected to the architecture behind them. Great software is not just reliable under the hood; it also needs to feel coherent to the people using it.

AI and the Compression of Implementation

AI is shifting from something teams experiment with to something the stack increasingly assumes.

What interests me is not just AI as a coding tool, but AI as a pressure test for how we build software in the first place. As implementation gets cheaper, the leverage moves upward: into judgment, architecture, constraint-setting, and the ability to keep systems coherent while output accelerates.

Used well, AI can speed up implementation, exploration, and iteration. Used poorly, it can flood systems with noise, overproduction, and shallow confidence. That makes this less a story about replacing engineering fundamentals and more a story about exposing how important they always were.

The Bigger Picture

I like powerful tools. I like elegant systems. I like good abstractions.

But I do not believe technology choices should be made in isolation from the business problem or the reality of the system. The best stack is rarely the trendiest one. It is the one that fits the problem, supports the team, and continues to make sense as the software grows.

That is the lens I bring to technology: choose tools deliberately, design systems that can hold up under pressure, and never confuse technical motion for architectural clarity.