Senior Network & Systems Engineer.

Operational data lived in systems people had to log into, so nobody looked at it between incidents. Chat is where the team already is, so I put the data there: a Zoom Team Chat bot backed by our internal APIs, answering on demand. It then became the natural surface for security triage — when a suspicious sign-in fires, the bot does the lookup a human would have done and posts the verdict.

• Zoom Team Chat bot with slash commands, running through a Zoom OAuth app against internal service APIs.
• On-demand operational stats — no console login, no context switch.
• Suspicious sign-in IPs validated against reputation and geolocation sources automatically.
• Confirmed results posted to the owning channel with the detail needed to escalate or dismiss.

Stack

• Zoom Team Chat API
• Zoom OAuth
• Webhooks
• n8n
• REST APIs

The recurring cost of running a managed service isn't the hard problems — it's the same checks, every morning, forever. Sign-in logs to review, licenses to reconcile, alerts to route to whoever owns them. I stood up a self-hosted n8n instance on our own infrastructure and moved that work into workflows, so the platform does the reading and engineers only see what actually needs a decision.

• Microsoft 365 sign-in monitoring — risky and impossible-travel events pulled from Graph, enriched with IP reputation, and pushed to the right chat channel with the context needed to judge them.
• Alert routing and deduplication across security platforms, so one incident produces one notification instead of five.
• Scheduled license and tenant reporting, replacing a manual per-client console walk.
• Autotask hooks that open, update, and annotate tickets directly from workflow output.
• Self-hosted end to end — credentials held in our own secret store, no client data leaving infrastructure we control.

Stack

• n8n (self-hosted)
• Microsoft Graph API
• Autotask REST
• Zoom API
• Docker

Managed Chromebooks are easy to deploy and hard to see into. Native Workspace reporting answers "what device is this" but not "what is this fleet actually doing all day." I built a multi-tenant platform where each client is an isolated tenant, a Chrome extension reports browser activity from the device, and the console turns that stream into productivity reports, policy enforcement, and alerts an operator can act on.

• Chrome extension that enrolls against a per-tenant key, reports sessions and events, and enforces blocking policy locally — with a revoke-first lifecycle so a device can be moved between tenants cleanly.
• User-bound enrollment: a device only enrolls if its signed-in user is registered or its email domain is allowed, with CSV import and a review queue for rejected attempts.
• Domain categorization with per-tenant overrides, driving both reporting and rule-based blocking.
• Alert rules, geofencing with IP-derived device location on a live map, and push notices delivered to one device or the whole fleet.
• Executive PDF reports generated in-app, split into an organisation view and a per-person view.
• Guided tenant onboarding, single-use admin invite and password-reset links with expiry, and a full audit log — no email service required to operate it.

Stack

• Next.js 14
• React 18
• Prisma + PostgreSQL
• Chrome Extension MV3
• Tailwind
• Recharts
• Leaflet
• JWT + bcrypt
• Zod
• Vitest
• Docker Compose

Zoom Phone generates an AI summary for every call, and Autotask needs a ticket for every billable one — but wiring them straight together means garbage tickets from wrong numbers, personal calls, and summaries that misread the conversation. OrbIT is the review layer in between: the call arrives, the summary is fetched and presented, an engineer decides in one screen, and only then does the automation run.

• Zoom webhook receiver with signature validation, pulling full call detail and AI summary back through the Zoom API and persisting the session.
• Review UI showing caller, direction, duration, and the AI summary with its suggested next steps — approve and the ticket is created, dismiss and nothing is.
• n8n handles the downstream work: company resolved from the phone number, contact found or created, Autotask ticket opened, time entry logged, ticket ID returned.
• Multi-user Zoom mapping so each engineer sees only their own calls instead of every call in the account — with role-based access for admins, managers, technicians, and viewers.
• Dashboard metrics over call volume and direction, plus a background sweeper that recovers calls Zoom delivers late or without a call ID.
• Closed the loop past the ticket: when a ticket completes, OrbIT emails a CSAT survey to the contact, records how they rated the interaction, and — on a good score — invites them to leave a Google Maps review. Support closure turned into a reputation channel.
• Hardened service: JWT auth, bcrypt, helmet, rate limiting, and a logic-check suite run against the phone, AI, matching, and sweeper paths before every deploy.

Stack

• Node.js + TypeScript
• Express
• Prisma + PostgreSQL
• React + Vite
• Tailwind
• Zoom Phone API
• n8n
• Autotask
• JWT + bcrypt
• Vitest
• Docker

Monitoring generates the same handful of alerts every day, and Autotask makes each one a multi-screen round trip: open the ticket, add a note, enter time, set status, go back. Multiply that by a morning queue and the tooling costs more than the alerts do. I built a console that puts the queue in front of you, shows what changed since you last looked, and closes each item in one action — so getting caught up is a single pass, not an hour.

• Dashboard of open tickets plus completed-today and completed-this-week counts — a straight answer to "where does this stand right now."
• Monitoring queue on one screen with inline work notes, time, work type, and resolution status; submitting logs the time entry and moves the ticket status in a single call.
• Kills the repetitive-ticket problem: recurring alerts are resolved against what already exists instead of spawning a new ticket per occurrence.
• Engineers, roles, statuses, and work types cached from Autotask reference data and refreshed on demand, so the pickers are instant instead of round-tripping the API on every load.
• Multi-user with per-user credentials, encrypted API secrets at rest, and its own login and session handling.

Stack

• PHP
• Autotask REST + SOAP
• MySQL
• JavaScript / AJAX

AI is useful against exactly the data you're least allowed to send anywhere — ticket histories, call notes, tenant configuration. Rather than accept that trade, I built local inference on GPU-enabled hardware inside our own network, and pointed the automation platform at it. Anything sensitive is summarized, classified, and drafted locally; only work that genuinely needs a frontier model goes out.

• Ollama serving local models on GPU-enabled infrastructure, sitting on the internal network behind existing segmentation.
• Wired into the n8n workflows as an inference backend for summarization, classification, and drafting.
• Keeps sensitive operational data inside infrastructure we control — no third-party API in the path.
• Private AI services available to the team without per-seat SaaS cost.

Stack

• Ollama
• GPU compute
• Linux
• Docker
• n8n

Everything else on this page needs somewhere to run. This is that layer: an on-premises virtualization platform hosting the automation stack, the local AI infrastructure, and internal services — designed so that a compromise in one plane doesn't reach the others, and so backups survive the thing they're backing up.

• Proxmox cluster running VMs and containers, with Docker for the application workloads on top.
• Management, production, and backup traffic separated onto distinct VLANs with routing restricted between them.
• Dedicated backup infrastructure isolated from the production plane, so ransomware on a production host can't reach the restore point.
• Hosts the n8n automation stack, local AI inference, and internal services described elsewhere on this page.

Stack

• Proxmox VE
• Linux
• Docker
• VLAN segmentation
• Backup & DR

Second generation. I had already built an operations platform for a logistics business in a previous role, run it in production, and learned where that design bent under real use — so this one started from the answers instead of the questions. The client was working out of spreadsheets and handwritten lists: packages logged twice, shipments reconstructed from memory, remittances tracked separately from the parcels they travelled with. I modelled the actual business — clients, packages, shipments, destinations — and built an admin platform where each package is registered once, grouped into a shipment, and follows a status through to delivery.

• Package intake with per-client validation that blocks duplicate pending entries at the source, where the errors were being introduced.
• Shipment consolidation: many packages grouped into one shipment, with generated manifests and PDF labels and lists.
• Remittance handling, so money moving with a parcel is tracked against the same record rather than in a parallel sheet.
• Geographic model of provinces and municipalities to drive delivery routing.
• Role-based access control, record versioning, user impersonation for support, and bilingual UI (ES/EN).

Stack

• Laravel 11
• Filament 3
• PHP 8.2
• MySQL
• DomPDF
• Tailwind + Vite
• Pest