$ when something breaks, I find the root cause — not just the symptom.
I troubleshoot code, APIs, integrations, automation workflows, websites, and production systems to identify what's actually failing and implement a reliable fix.
Not every technical problem can always be fixed — but most can be properly diagnosed. These are the kinds of symptoms I investigate every week.
A symptom and a root cause are rarely the same thing. Patching the symptom often means the same problem comes back — sometimes worse, sometimes somewhere else.
Reproduce the problem consistently where possible — an intermittent bug and a consistent one need different approaches.
Review code, requests, responses, logs, workflows and data rather than guessing.
Determine which component or dependency is actually failing, not just where the error surfaced.
Separate the underlying cause from the visible symptom before deciding on a fix.
Implement the smallest reliable fix appropriate to the actual problem.
Test normal behavior, edge cases and failure scenarios — not just the happy path.
Confirm the fix works in the real environment before considering it resolved.
I investigate and diagnose each of these, and implement a fix where one is possible — not every problem has a guaranteed resolution, but every problem can be properly understood.
API problems can come from authentication, permissions, incorrect endpoints, request formatting, response changes, rate limits, missing fields, unexpected data, webhook behavior, or a third-party service changing how it behaves. Debugging these requires inspecting the actual request and response — not guessing based on the error message alone.
What is software debugging? Software debugging is the process of finding the cause of unexpected software behavior, correcting the underlying problem, and testing the system to verify that the fix works — not simply making an error message disappear.
Automation failures across n8n, Make, Zapier and GoHighLevel usually trace back to a handful of causes: failed executions, wrong branches, missing data, duplicate actions, incorrect field mapping, API errors, timing issues, or webhook problems. I trace the actual execution data through the workflow — webhooks, APIs, CRMs and databases included — to find exactly where it breaks. See n8n automation, CRM automation, and GoHighLevel automation for the build side of this work.
I don't automatically recommend rebuilding software. When appropriate, I work with an existing codebase, understand the current architecture, reproduce the problem, identify the cause, and make a targeted fix. For work that goes beyond fixing what exists, see software engineering services.
Real projects with real investigation work, not hypothetical scenarios. Full detail on each is on the case studies page.
Some bookings showed incorrect $0 revenue figures.
Compared raw API responses against the platform's own CSV export to determine whether the issue was upstream or in the integration.
Confirmed a genuine upstream data limitation and built the system to flag those bookings for manual review instead of silently showing wrong figures.
An application built on a no-code AI platform needed to run independently.
Audited every dependency the app relied on — data, content, AI features, file storage, server-side logic.
Replicated the required functionality on self-hosted infrastructure with no ongoing platform dependency.
Back-in-stock alerts only worked per-product, not per-variant.
Audited the store's app settings to confirm the limitation was structural, not a misconfiguration.
Built a custom per-variant notification feature for the store's specific workflow.
Customer and order data required manual CSV exports to reach Customer.io.
Mapped what WooCommerce could expose via webhook versus what needed a scheduled pull.
Built a direct, real-time integration between the two systems.
Conversations required a person to manually reply to every message.
Identified where a fixed reply flow was sufficient versus where drop-off actually needed a follow-up trigger.
Built the core conversation flow plus an automated re-engagement sequence for customers who stopped responding.
The right debugging approach depends on the system and the failure, not simply the programming language.
When the answer points toward rebuilding rather than fixing, that work falls under software engineering instead.
Give me the symptoms, the system involved, and what you've already tried. I'll help identify what needs to be investigated and determine the most practical technical path forward.