Services
Six practices, one engineer
Most engagements start in one of these and quietly touch the others, because real systems don’t respect the boundaries between them.
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.
Typical tooling
- Azure
- AWS
- Terraform
- Bicep
- Kubernetes / 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.
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.
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.
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.
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.
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
Working together
Three ways to engage
Assessment
Usually fixed feeA defined review of one area — infrastructure, security posture, an application, or an architecture decision. It ends in a written report with prioritized findings.
Best forYou suspect something is wrong but want it named precisely before spending on a fix.
Project
Scoped & quotedA defined build or migration with agreed deliverables and milestones, quoted up front wherever the shape of the work allows it.
Best forYou know what you need built and want a predictable path to it.
Retainer
MonthlyOngoing access to a senior engineer: a standing block of hours for advisory, review, escalation, and steady improvement work.
Best forYou want senior judgment available continuously, without a full-time hire.
Questions
Before you call
Do you work remotely?
Yes — remote, end to end. Reviews, working calls and handover all happen over Teams, Slack or Zoom, whichever your team already uses. I don’t run in-person workshops or training days; that isn’t the shape of help I’m good at, and a written runbook outlasts a room full of people nodding. If something genuinely physical comes up — hardware, a network cutover — that’s worth a conversation, but it’s the exception rather than something I build engagements around.
How do you charge?
Assessments are usually a fixed fee. Projects are scoped and quoted up front wherever the shape of the work allows. Ongoing work runs on a monthly retainer. Whatever the shape, I’d rather you know the price before you commit than find out as we go.
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.
What size clients do you take on?
From single-founder companies through mid-size organizations, plus subcontract work with larger firms. Size matters less than whether it’s the kind of problem where experience actually changes the result.
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.
How much of your time is actually available?
W3Fix runs alongside a full-time senior engineering role, so I take a small number of engagements at a time rather than filling a pipeline. In practice that means assessments, defined projects and retainers with a realistic cadence — not emergency cover or staffed on-call. If your timeline needs more hours than I have, I’d rather say so on the first call.
What if you’re not the right person for this?
I’ll tell you, ideally on the first call. 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.