Technical capability
Build and diagnose in the same week.
How I work across data, media platforms and code, and what that changes about turnaround.
The short version
I work directly in the systems: SQL against your own tables in Postgres and Supabase, Python for the reconciliations, APIs and connectors I build myself, and version-controlled build environments. I can stand up a lead-flow schema, a reporting layer or a working internal tool while we are still diagnosing, instead of waiting a quarter in a dev queue to confirm what the numbers already suggest.
My job is not shipping production software. It is getting from a question to a working artifact fast enough that the answer still matters, and knowing which artifact is worth building at all. When something needs to hold up at scale, my team takes it from there.
What the stack actually covers
- Data and SQLPostgres, Supabase, direct SQL against client tablesSchemas, lead-flow models, reporting views, ad-hoc analysis
- AnalysisPython with pandas and numpy, in a live shellReconciliations, cohort and funnel math, statistical checks
- Platform APIsCustom connectors built for ad, tracking and affiliate platformsDirect read and write against live campaign and conversion data
- Cross-platformThose connectors queried together in one sessionOne click followed from ad spend through to recorded lead
- Edge computeCloudflare Workers, D1 and KV, with agents deployed at the edgeEndpoints you own instead of partner-dependent webhooks
- AutomationScheduled jobs, recurring analysis, alertingMonitoring that runs without me in the room
- Web propertiesSite porting, DNS, hosting, browser-based deploysLanding pages and funnel tests live the same day
- FunnelsMulti-step lead flows, form and quiz logic, call and click pathsThank-you and remarketing paths wired end to end
- Copy and offerPage and ad copy, angle and hook developmentOffer framing written for the vertical, not generic
- Response creativeStatic and video ad concepts, landing page designCreative built against an audience response, not brand decoration
- BuildGitHub and AI-assisted build environmentsWorking internal tools and proof-of-concept apps
- BrowserAutomated interface operation where no API existsChanges applied when the platform's API is closed
Where a platform's API is locked down, I drive the interface directly instead.
Connectors that talk to each other
Off-the-shelf integrations let you look at one platform at a time. I build custom connectors that turn a platform into a queryable data source instead of a source of CSV exports and screenshots. The constraint is the quality of the API, not the platform.
The value is not any single connector. It is running them together in one session. Ad platforms know what you spent. Affiliate and tracking platforms know what converted. Neither can see the other. When both are queryable at once and sub-ID parameters are passed correctly, a single click can be followed from the placement that served it, through the ad platform's billing, into the tracking platform's conversion record.
That join is where the real problems turn up: the ad platform reporting healthy delivery, the tracking platform reporting healthy conversion, and only the two side by side showing that one source is billing for clicks that never became a lead.
No waiting on someone else's roadmap
The default answer to "these two platforms need to talk" is a webhook, which means filing a request with the other party, waiting for their developer to build and configure an endpoint, and living with their timeline and their reliability.
Instead I deploy an agent at the edge. I own it, and it does the work the webhook would have done without anyone else having to ship anything. That turns a multi-week partner dependency into something standing up the same day, and when it needs to change I change it instead of reopening a ticket.
It matters most when the partner integration is the thing under suspicion. If the question is whether the other side is firing correctly, owning your half of the pipe is the difference between diagnosing it and waiting to be told.
The landing page as well as the traffic
I also stand up and operate the web properties the campaigns point at. On a recent engagement that meant porting an existing site with tooling rather than rebuilding it by hand, repointing DNS, and setting up an edit-and-deploy loop that runs through the browser: change the page, push it live, no pipeline and no developer in the path.
The reason that matters is not that a landing page is hard to host. It is that in paid acquisition the page and the traffic are one system, and they are almost always owned by two different people. When the media buyer has to file a ticket to change a headline or a form field, testing happens at the speed of someone else's backlog.
Controlling both means a theory about why traffic is not converting gets tested against the page the same day it comes up, and when the funnel itself turns out to be the constraint, that is something I can act on instead of hand off. What goes on the page is mine too, not just where it is hosted.
The offer, not just the plumbing
I build the sites and the funnels, write the copy that runs on them, handle the design, and develop the response creative that feeds them. Angles, hooks, form and quiz logic, call paths, thank-you and remarketing steps. Not brand work. Creative built to produce a specific response from a specific audience.
Most people who can query the data cannot write the page. Most people who can write the page cannot see the data. Splitting those two is why a bad angle survives for a month: whoever spots it in the numbers has to convince whoever owns the words, and then wait for a designer.
Doing both means a losing angle gets rewritten, redesigned and back in market the same day it shows up, and the creative gets judged against recorded conversions rather than platform-reported clicks.
Why this compresses timelines
The conventional path is an analyst pulling exports, a deck, engineering scoping the fix, and the fix entering a sprint queue. Four to twelve weeks before anyone knows whether the theory was right.
Working this way, diagnosis and remediation happen in the same session, and the monitoring that prevents a repeat gets built before the engagement ends. What is actually being bought is not code. It is the removal of the wait between suspecting something and confirming it.
On a recent engagement, a campaign that was reported to me as "the tracking is broken" went from that sentence to a confirmed diagnosis, a set of applied remediations and two automated recurring reviews inside about a day of work. I will walk through the specifics on a call.
Where the line is, and who crosses it
Being straight about this is what makes the rest of it credible.
- What I build myself is diagnostic and operational grade: tools that answer a question, run a workflow, or put a page and a funnel in market. That is deliberate, and it is what makes the turnaround possible.
- Production systems, security review and anything carrying uptime obligations go to engineers. I scope it, I stay on it, and my team builds it. Escalation is part of the engagement, not a gap in it.
- Access sets the ceiling. Read-only credentials mean read-only work, and an undocumented or throttled API limits what a connector can return. I will tell you that up front rather than after the invoice.
- Every change gets verified against the API, because platform interfaces fail silently. If something did not apply, you hear it from me first.
If the question you have is one of these, the fastest way through it is a short call rather than a scoping document.
Request a Revenue Triage Call