About
I build automation systems for teams that have to live with them.
I'm an Ops & Automation Engineer working across multiple client accounts. Most of my work is in n8n, Zapier, and custom code where the no-code tools run out of room.
I build automation workflows, API integrations, and eCommerce customizations that connect CRMs, payment systems, and marketing tools into something coherent.
What I focus on is the work after launch. I'd rather deliver a system that stays reliable and documented than one that only I understand.
Services
What I work on
| Service | Category | Stack |
|---|---|---|
Multi-stage automation pipelines Connecting business systems end to end across triggers, transforms, and actions | Automation | n8nZapierMakeNode.js |
API integration Custom REST and GraphQL integrations across CRMs, eCommerce platforms, and marketing tools | Integration | RESTGraphQLHubSpotShopify |
AI pipeline design Structured outputs, prompt engineering, schema validation, and cost-conscious model use | AI / ML | Claude APIGeminiWhisperPython |
Web scraping & data extraction Workflows for research, monitoring, and lead generation | Data | Apifyn8nSerpAPIJavaScript |
Shopify storefront work Theme customization, Liquid templating, and DNS migrations | eCommerce | LiquidShopifyCSSDNS |
Email campaign automation Campaign production and lifecycle automation across email platforms | Marketing | KlaviyoMailchimpn8n |
Custom internal tools Dashboards and interface blocks primarily in Airtable with React | Tools | AirtableReactNode.js |
Debugging live systems Diagnosing broken workflows, API integrations, and data issues in client systems | Support | n8nZapierAPIs |
Technical documentation Handoff-ready SOPs so systems can be owned by the team after launch | Docs | NotionMarkdown |
Philosophy
How I think about systems
Built to outlast me
I build for the team that will inherit the system, not for the demo. A production system is a promise to the person on call at 2 a.m. when something breaks.
Boring is correct
Reliable writes, explicit retries, clear logs, and versioned contracts beat clever abstractions. Most of the outages I've seen came from the clever part.
Context before code
Before I propose a solution, I look at what you already have running, how the end user experiences it, and whether there's a newer tool worth considering. The ticket is usually the symptom, not the problem.
No surprises at launch
If something is doable but a bad idea, I lay out the trade-offs so we can decide together. Nothing ships without going through my own QA pass first. A bug I catch is cheaper than a bug you do.