Consultancy
Senior software engineering and architecture consultancy. From system design to hands-on implementation.
Helping engineering teams build systems that last
Your system works today. The question is whether it’ll hold up under 3× the load, after the team doubles, or when that critical service you’ve been papering over finally breaks.
I work with engineering teams on the problems that matter most: systems that are hard to change, architectures that don’t scale, reliability issues that are eating engineering time, and technical debt that’s slowing everything down.
What this looks like in practice
Engagements vary depending on what your team actually needs. Some are purely advisory — regular sessions to work through architectural decisions, review proposals, and challenge assumptions. Others are hands-on — embedded with your team, writing code, doing reviews, and helping implement the changes we’ve designed together.
Architecture and system design
Most architectural problems aren’t hard to diagnose once you’re willing to look at them honestly. The coupling that shouldn’t be there, the service boundary that made sense two years ago but now causes pain, the database that’s being asked to do too many things at once.
I help teams identify and address these problems systematically, not with a full rewrite, but with a clear-eyed view of the tradeoffs and a realistic path forward.
Distributed systems
Building systems that communicate over a network is fundamentally different from building monoliths. Failures are partial, ordering is unreliable, and consistency is hard to reason about. Teams that haven’t built this before often discover this the hard way.
I’ve worked extensively with event-driven architectures, message queues, consensus systems, and the patterns that make distributed systems behave predictably under failure conditions.
Backend engineering
Deep JVM expertise — Java and Kotlin with Spring Boot, performance tuning, GC behaviour, concurrency. Also Go and Node.js for services where they fit better. I care about the quality of the code, not just whether it deploys.
Cloud architecture
AWS-first but cloud-agnostic in approach. Infrastructure design, cost efficiency, security posture, and the operational concerns that teams often neglect until something goes wrong in production.
Technical strategy
Sometimes the most valuable thing isn’t a technical solution — it’s a clear view of the technical landscape and a strategy for navigating it. Technology roadmaps, build-vs-buy decisions, platform choices, team structure.
Who this is for
- Engineering teams that are moving fast but starting to feel the friction of accumulated architectural decisions
- Companies where the codebase has grown faster than the architectural thinking
- Teams dealing with reliability, scalability, or performance problems that are hard to pin down
- Engineering leads who want a senior outside perspective on decisions they’re wrestling with
What I don’t do
I don’t write reports that sit on a shelf. Every engagement produces something the team can act on — whether that’s a concrete architectural plan, a working prototype, improved tooling, or better clarity on what to build next.