Case Study - Front-end forensics on Shopify storefronts

Overview

Technical support at a platform company is really three jobs in one: a debugger, a triage analyst, and a technical writer. The hardest part isn't fixing the bug — it's correctly identifying which layer of the merchant's stack the bug actually lives in, then explaining it without making the merchant feel out of their depth.

At Rebuy, I worked across all three.

What I worked on

Front-end debugging in customer theme files

When a Rebuy widget rendered incorrectly, broke a checkout flow, or collided with another script on a merchant storefront, the resolution often required me to write or edit JavaScript, CSS, and HTML directly inside the merchant's Shopify theme. That meant working in Liquid alongside JS — reading other developers' code, identifying CSS specificity conflicts, and patching widget rendering without destabilizing the rest of the theme.

Chrome DevTools as the primary diagnostic surface

I spent most of my day in Chrome DevTools — inspecting DOM state, tracing network calls, watching console errors, and isolating root causes across JavaScript conflicts, CSS cascade issues, and third-party script interference. The DevTools workflow is what kept fixes precise instead of "just toss !important on it."

Triage across the merchant's stack

A lot of customer-reported issues looked like front-end problems but were actually purchasing-system or inventory-data problems — and vice versa. I learned to read the symptoms carefully enough to route the issue to the correct resolution path: theme/widget layer, purchasing logic, or data source. That triage discipline prevented surface-level fixes that would have surfaced again a week later.

Platform integration issues

I assisted customers through Rebuy integration setup — diagnosing authentication errors, walking through OAuth scopes and API tokens, and resolving incorrect data source configurations so their stores could actually connect to the platform and start running campaigns.

Customer-facing technical writing

I authored diagnostic reports and customer-facing communications via Intercom and Jira. The job was to translate "this widget broke because a third-party app's mutation observer was clobbering our React root" into something a merchant could actually act on, without losing the technical accuracy that an engineer downstream would need to verify the fix.

What I took from it

The role made me sharper at three things I lean on now: tracing a bug from symptom to actual cause across multiple layers, writing technical explanations that respect the reader's time, and resisting the temptation to "fix" something at the wrong layer just because the wrong-layer fix is faster.