Services
Six practices, one engineer
Most jobs start in one of these and quietly end up touching the others. The boundaries are clear on the diagram; they are less so in a system that has been in production for a few years, and closing that gap is most of the work.
Cloud & Platform Engineering
Most infrastructure problems are not capacity problems. They are memory problems: the environment was built by hand, the reasoning lived in one engineer’s head, and nobody can rebuild it under pressure. I turn that into infrastructure as code — declarative, reviewed, and repeatable — then wire up the deployment pipelines, observability, and cost controls that keep it healthy. The goal is boring infrastructure: the kind you can hand to a new hire on a Tuesday.
In practice, most of this is automation. Environments are rebuilt rather than patched in place, so a fleet takes its updates by being redeployed from a known-good definition instead of drifting further apart with every hand-applied fix. Rollouts are gated on validation tests and staged rather than switched over all at once, which is what keeps a bad release from becoming an outage. Where a failure is well understood and the fix is safe to apply unattended, the alert triggers the remediation directly — so routine problems resolve themselves and a person gets woken for the genuinely novel ones.
Typical tooling
- Azure
- AWS
- Terraform
- Bicep
- Kubernetes / AKS / EKS
- Docker
- Helm
- Ansible
- GitHub Actions
- Jenkins
- Azure Monitor
- Grafana
What you get
- Infrastructure as code covering your environments end to end
- CI/CD pipelines with automated testing, staged rollout, and clean rollback
- Monitoring, logging, and alerting that pages a human only when it should
- Cloud cost review with prioritized, quantified reduction opportunities
- Runbooks and architecture docs your team will actually keep current
Security, DevSecOps & IAM
Security that lives in a separate checklist gets skipped. Security that lives in the pipeline gets enforced. I work on the identity and access layer first — who can reach what, under which conditions, and how that is proven — because access sprawl is the single most common finding I encounter. From there: dependency and secret scanning in CI, hardened build and deploy paths, sane key management, and least-privilege policies that engineers can live with rather than route around.
Access reviews and secret rotation are the kind of work that gets done thoroughly once and then quietly decays, so I automate the recurring parts: scanning on every change in CI, rotation on a schedule rather than a calendar reminder, and access recertification that produces its evidence as a by-product instead of a scramble in the week before an audit. The aim is that the secure path is also the path of least resistance — engineers route around controls that cost them time, and a control that gets bypassed is not a control.
Typical tooling
- SailPoint
- Okta
- Entra ID
- Active Directory
- CyberArk
- Azure Key Vault
- AWS Secrets Manager
- TruffleHog
- OAuth2 / OIDC
- SAML
- Zscaler
- Zero Trust
What you get
- Identity and access review with a concrete least-privilege remediation plan
- Secrets management: rotation, storage, and removal from source history
- Automated dependency, container, and static analysis scanning in CI
- System and network hardening across Linux, Windows, and cloud accounts
- Evidence and documentation to support SOC 2, HIPAA, or PCI readiness work
Software & Data Delivery
I build the systems businesses run on: internal tools, customer-facing applications, APIs, and the integrations that stitch existing software together. Underneath almost all of it is a data model, and a bad one will limit an application for its entire life — so schema design gets real attention up front. I write code the way I would want to inherit it: tested, documented, conventional, and free of clever tricks that only make sense to the author.
A good deal of delivery work is removing work. Recurring manual steps — a report assembled by hand every Monday, data moved between two systems on a schedule somebody has to remember, onboarding that costs a checklist and an afternoon — are usually better expressed as code that runs unattended and says something when it fails. That is often the highest-value part of an engagement: not the new application, but the hours a week it hands back to the team that has to operate it.
Typical tooling
- Python
- PowerShell
- C# / .NET
- ASP.NET
- SQL Server / T-SQL
- PostgreSQL
- Cosmos DB
- MySQL
- SSIS
- JSON Schema
- REST
What you get
- Web applications and internal tools, from data model through deployment
- APIs and integrations between systems that were never designed to talk
- Relational schema design, query tuning, and migration strategy
- Legacy modernization — including systems whose original authors are long gone
- Automation that removes recurring manual work from your team’s week
Legacy Systems & Integration
Most consultancies want to replace this class of system. I would rather understand it first. I have written the interface between a modern Windows application and an IBM 3270 mainframe, automated nightly z/VSE operations, and built inventory collection across environments nobody had mapped in years. That work needs patience and a certain respect for whatever is already running — the code that has quietly processed transactions for a decade is usually load-bearing for a reason. Once it is understood and documented, you get a real choice about whether to modernize it, wrap it, or leave it alone.
Automation is what makes this class of system safe to touch. Inventory collection and dependency mapping run repeatedly rather than once, so the picture stays accurate while the work proceeds rather than going stale the day it is written. Nightly operations, terminal interactions, and batch jobs that depend on somebody being awake are the first things to move into scheduled, monitored, re-runnable code — which removes the toil and, more importantly, removes the single-person dependency that made the system frightening in the first place.
Typical tooling
- IBM 3270 / CICS
- Attachmate VHI
- z/VSE
- WMI
- SOAP / XML
- ServiceNow
- LeanIX
- SSIS
- SQL Server
What you get
- A map of what actually exists, what it talks to, and what is load-bearing
- Integration between systems that were never designed to talk to each other
- Terminal and mainframe automation where no modern API exists
- Migration sequencing that does not require a big-bang cutover
- The documentation that should have existed all along
AI & Local LLM Engineering
Most AI tooling assumes you are comfortable sending your documents to somebody else’s API. For a lot of businesses — healthcare, legal, finance, anyone under a confidentiality obligation — that is the end of the conversation. I build the other kind: local inference, structured output, and pipelines designed around the fact that models are confidently wrong sometimes. That means cross-verification rather than trust, confidence gating before anything is acted on, and destructive operations that are dry-run by default. This is currently my own engineering practice rather than a client track record, and I would rather say that plainly than imply otherwise.
The guardrails are the engineering. Destructive operations are dry-run by default, extracted output is cross-verified against its source rather than trusted, and anything acted on without review has to clear a confidence gate first. Applied with that discipline it fits the automation work above well — classification and extraction at volume is exactly the sort of toil that quietly consumes people — but it earns the same validation any other unattended remediation has to pass, and no more trust than that.
Typical tooling
- Ollama
- Llama 3.2 Vision
- Gemma 3
- Whisper
- PostgreSQL
- Qdrant
- Python
- tesseract OCR
- OpenCV
What you get
- Local model deployment — inference on your hardware, no data leaving it
- Document intelligence: classification, extraction, deduplication at volume
- Retrieval pipelines with citation provenance, so answers can be checked
- Structured extraction with cross-verification against the source
- Guardrails for AI coding agents — scoped permissions, reviewed scripts, dry runs
Architecture Review & Due Diligence
The most expensive decisions on any system get made at the beginning, when you have the least information. I review designs before they’re built and systems after they’re inherited: what the tradeoffs actually are, what will hurt in two years, and what can safely be left alone. That includes the unglamorous version — reading someone else’s architecture, mapping an integration nobody has documented, or working out whether the platform you’re acquiring is worth what you’re paying for it. Often the most valuable thing I deliver is talking someone out of an expensive rebuild they didn’t need.
Reviews often end up pointed at toil. A system that demands constant manual attention is usually saying something about its design, and the cheapest fix tends to sit upstream of whatever is actually being complained about. So I look at where the operational effort genuinely goes, how much of it is automatable, and how much is a symptom worth fixing properly instead — including the cases where automating something would cost more than doing it less often, which I would rather say out loud than quietly build.
Typical tooling
- Architecture review
- Technical due diligence
- Platform design
- Integration design
- Migration planning
- Vendor evaluation
- Mentoring
What you get
- Architecture and system design review, with the tradeoffs written down plainly
- Platform and integration design for systems that have to talk to each other
- Build vs. buy and vendor evaluation, with the reasoning documented
- Technical due diligence on an acquisition, a vendor, or a system you inherited
- Mentoring for engineers and leads growing into architecture decisions
Automation
Doing it once, then not again
This runs through everything above rather than sitting beside it. Given a choice between doing a thing carefully and teaching a system to do it carefully, I will generally choose the second — because the automated version is the one that still gets done correctly on a bad week, and it writes down how the work is performed as a side effect of performing it.
Remediation that runs itself
When a failure is well understood and its fix is safe to apply unattended, the alert should trigger the fix rather than a person. That keeps human attention for the failures nobody has seen before, which are the ones worth a human.
Patching by redeployment
A fleet patched in place drifts, one host at a time, until no two machines are quite alike. Rebuilding from a known-good definition instead means the update and the disaster-recovery rehearsal are the same exercise, run often enough to be boring.
Validated, staged cutover
Whole platforms can be bootstrapped and deployed alongside what is already running, with the cutover gated on validation tests and a clean path back if those tests fail. Designed properly, users see a version change rather than an outage window.
Toil, where it is actually felt
The work worth automating is rarely the work that looks impressive. It is the Monday report, the manual approval, the runbook step everyone half-remembers — operational and developer experience, where a small amount of automation returns hours every week.
Process, not only systems
Not all toil is technical. Plenty of it is a handoff, an approval, or a status update that exists because no one has questioned it. I am happy to automate those too, and equally happy to point out the ones that should simply stop.
Shapes
What the work usually looks like
Reviews and assessments
Looking hard at one thing — an environment, a security posture, an application, an architecture decision that has not been made yet — and writing down what is actually true about it. These end in a document someone can act on without me.
Builds and migrations
Infrastructure written down and version controlled, pipelines that deploy without ceremony, systems moved from where they were to where they need to be. Scoped up front, delivered in increments you can see.
Untangling what is already there
The system that still runs the business, that nobody wants to touch, whose author left years ago. Working out what it does, writing that down, and making it safe to change — which is usually more valuable than replacing it.
Questions
Questions worth answering
Will you work with my existing team or vendors?
Regularly, and happily. A good outcome usually means making the people already there more effective rather than replacing them. I’m comfortable joining an existing team, coordinating with incumbent vendors, and handing work off cleanly when the engagement ends.
Can you take over a system nobody understands anymore?
That’s one of the more common reasons people call. Undocumented systems, a departed engineer, a platform still running on an unsupported version — mapping what exists and making it safe to change is normal work here, not an exception.
What if the work turns out to be smaller than expected?
Then it should cost less, and I’ll say so. If an assessment finds your real problem is a two-hour configuration change, you’ll hear that rather than a proposal built around it.
What if you’re not the right person for this?
I’ll tell you, as early as I can tell. Being a generalist means knowing where my range runs out, and an honest referral costs me one engagement while a bad fit costs us both a lot more.
Not sure which one you need?
That’s a completely normal place to start. Describe the situation and I’ll tell you which of these it actually is — or that it’s none of them.