What I actually do for you.

AWS in depth, Azure from a full migration and five years running it in production, Google Cloud kept current. I build cloud estates that a regulator, an auditor or a new engineer can all make sense of.

What that looks like

• Multi-account estates with real separation of duties, not one account and good intentions
• Networking, identity and access designed once, properly: Auth0, OpenID Connect, OAuth2, Okta federation
• Container platforms on ECS Fargate or Kubernetes, with the data tier to match
• Cost reviewed honestly and early, because as a founder the budget has usually been my own

Production C# since the first release of .NET, and still writing it this week. Event-driven services, REST and messaging APIs, and domain-driven design applied where it earns its keep rather than everywhere.

What that looks like

• Service and microservice architecture, including the judgement to leave a working monolith alone
• Event-driven and messaging patterns, CQRS, integration across systems that were never meant to meet
• APIs designed for the people who have to consume them, versioned so you can change your mind later
• The data underneath: SQL Server and PostgreSQL modelled properly, document and NoSQL stores where they genuinely fit, and the ORM picked for the job rather than out of habit
• TDD and BDD, and a test suite the team trusts enough to act on

Terraform across the whole estate, not just the easy half. The pipeline work that turns a two-week release into a twenty-minute one, and a deployment your engineers will run on a Friday afternoon.

What that looks like

• Existing infrastructure brought under Terraform without a big-bang rewrite
• CI/CD on CodePipeline, GitHub Actions or Azure DevOps: build, test, scan, deploy, roll back
• Environments that are reproducible, so staging actually predicts production
• Bicep where an Azure-native team will maintain it after I have gone

The newest thing on this list, and I would rather say so than have you find out. I am deep in Google Cloud’s data and ML track and applying it on live work. What I can give you today is the MLOps half, which is mostly platform engineering wearing a different hat, plus straight answers about the rest.

What that looks like

• The pipeline and platform around models: data in, features, training, serving, monitoring, rollback
• BigQuery and BigQuery ML for teams whose ‘ML problem’ is really a SQL and data-engineering problem
• Embeddings, vector search and RAG wired into real applications, with the retrieval quality actually measured
• Your own tools and data exposed to models over MCP, with the access boundaries drawn deliberately rather than left wide open
• An honest read on whether your problem needs machine learning at all, often the most valuable thing I will say