Software architecture consulting

An architecture review is an internally-driven process focused on improving your system, identifying risks, bottlenecks, and the path to a better architecture. Technical due diligence is externally-driven, typically commissioned by an investor or acquirer to assess whether the technology is sound and the team is credible. Both involve deep system analysis, but the audience, outputs, and intent differ. I offer both, and they sometimes overlap: a rigorous architecture review often doubles as preparation for investor scrutiny.

It depends on the scope. A focused architecture review of a medium-complexity system typically takes two to four weeks to complete thoroughly. Embedded architect engagements run three to twelve months, depending on what you're building and how much guidance your team needs along the way. Advisory arrangements are open-ended by design. In the initial conversation, I'll give you a realistic estimate based on your system size, team capacity, and objectives.

Both, depending on what's most valuable. For architecture reviews, the deliverable is a structured document: findings, risks, and recommendations with clear prioritisation. For embedded engagements, I stay hands-on, reviewing code, writing proof-of-concept implementations, pairing with engineers on complex problems, and contributing to critical path work. I don't produce recommendations and disappear. The architecture only succeeds if the team understands it and can execute it.

Yes, and I'll be direct: microservices are often the wrong answer, especially for teams that aren't yet large enough to justify the operational overhead. The first thing I do is challenge whether decomposition is actually the right solution for your specific situation. If it is, I design the migration using the Strangler Fig pattern or domain-driven decomposition, extracting services incrementally rather than attempting a big-bang rewrite. The goal is always to maintain delivery velocity while the architecture evolves underneath.

I've worked across a wide range of backend and infrastructure stacks: Node.js, Python, Go, Java, and .NET on the backend; PostgreSQL, MongoDB, Redis, Kafka, and RabbitMQ for data and messaging; AWS, GCP, and Azure for cloud infrastructure; Kubernetes, Docker, and Terraform for deployment and IaC. Architecture principles transfer across stacks, as the patterns that make systems maintainable and scalable are largely language-agnostic. That said, I'm transparent about areas where I'd bring in a specialist alongside me.

Architecture that looks elegant on a whiteboard and fails in production is worse than no architecture at all. Every design decision I make is grounded in what your team can actually build, operate, and maintain given your current size, skills, and runway. I ask hard questions about operational complexity, team bandwidth, and migration cost. And I maintain a strong prior toward the simplest solution that solves the actual problem. Distributed systems, event sourcing, and CQRS are powerful patterns that are also frequently misapplied. The measure of good architecture is whether it makes your team faster and your system more reliable, not whether it matches a reference diagram.