How I work
The projects show what got built. This page is about how I get there — how I scope a problem, choose a tool, debug when something breaks, and keep a client in the loop the whole time.
Before any tool gets opened, I try to understand the actual problem — not just the feature request.
Most requests arrive as "can you automate X." I ask what happens right before and right after X — because the actual time sink is often one step over from where the client is looking. A form that's slow to fill out is a different problem than a form nobody follows up on, even though both get described the same way.
I trace the whole path end-to-end — trigger, decision points, where data lands, who gets notified — before touching a build canvas. This is where I catch edge cases early: duplicate submissions, missing fields, what happens if an API call fails halfway through.
I build the main success path first and test it with real data, not sample data. Edge cases, error handling, and notifications get layered on after the core flow is proven — so I'm never debugging five new things at once.
Make.com, Zapier, and custom code all solve overlapping problems — the deciding factor is usually cost, complexity, and how much control the client will need later.
| Situation | Tool I reach for | Why |
|---|---|---|
| Multi-branch logic, AI steps, higher volume | Make.com | Visual branching and iterators make complex conditional flows easier to debug and hand off later. |
| Simple trigger-to-action, client already has an account | Zapier | Faster to set up for linear flows, and most small business owners already recognize the interface. |
| Something no-code can't reach — custom parsing, one-off logic | Custom code / API calls | No-code tools hit real limits on custom data transforms; a short script is often more reliable than a workaround. |
Every automation breaks eventually — an API changes, a field renames itself, a trigger fires twice. This is the part that doesn't show up in a finished portfolio piece.
Reproduce before I touch anything. I find the exact input that caused the failure before changing a single module — guessing at fixes usually just moves the bug somewhere harder to find.
Check the data, not just the logic. Most "broken automation" issues are a field that changed shape upstream — a renamed column, a null value — not the workflow itself.
Add a safeguard, not just a patch. Once I know why it broke, I add a filter or error-handler so the same class of failure doesn't return in a different shape next month.
Log what happened. A short written note on what broke and what I changed means the next fix — mine or someone else's — doesn't start from zero.
An automation running quietly in the background is only reassuring if the client knows it's actually working.
Instead of "the automation is done," I send what it actually produced — a screenshot of the sheet updating, a sample email it sent, a real lead flowing through end-to-end. Clients running a business don't need workflow jargon; they need proof it works.
I also flag risk plainly before building anything: what happens if an API goes down, what a manual fallback looks like, and where a human still needs to step in. No surprises after launch.
→ get_in_touch