Shopify & E-commerce Engineer · 5 years in e-commerce, 3 on Shopify
From the offer and product decision to cart, checkout, measurement and a safe release. Stores in the US, Canada and Europe. You hand over the storefront and receive a finished result, with the open questions already answered.
Why me
I work with everything that genuinely speeds up delivery today: I evaluate new tools, test them on real work, and keep only what survives a live project. One example is a Figma MCP and Claude Code pipeline I built eight months ago and have refined on production stores since. What a client gets is not an experiment but a proven process.
The project does not wait on a designer, a manager, or a third-party review. Design refinements, asset generation, code, testing and release all pass through one pair of hands. When a task calls for a team, I assemble and lead it myself. I have done that before.
I treat every project as a sales funnel, not a task list. If I see a more effective way to move conversion than the one in the brief, I propose it before the work starts. Experience across dozens of stores shows which solutions bring sales and which only create the appearance of activity.
I find the cause, fix it, verify it and ship it to production without disturbing the content team's work. The complexity stays on my side. What reaches you is the finished result and a short summary: what changed and what to watch.
Tooling in practice
New tools earn their place on my projects only after they prove themselves on real work. The clearest example is the pipeline I built on Figma MCP and Claude Code eight months ago and have refined on production stores since. A frame comes in through MCP, Claude Code drafts the section against the theme's own patterns, and every spacing and radius is checked back against the design. The hours a developer used to spend on routine markup now go elsewhere: into testing that everything works correctly, into finding what is not quite right, and into more considered engineering, including the decisions that directly affect how fast the site loads. Routine markup is a thing of the past, and with it the era of endless revision rounds, sections built wrong the first time, and slow pages, which in e-commerce cost both sales and metrics. Where that era continues, it continues with other developers. The focus has moved to the result: a store that runs fast and without failures, which is exactly where the freed-up time now goes.
Where it helps
Generated output ships only after it has passed the codebase, the platform constraints and a clean-room check.
Featured project
A US wellness supplements brand under NDA. I redesigned the subscription offer itself: which plans to run, what cadence each pack maps to, how the price is presented so it always matches what the customer is billed, and a buy box on native Selling Plans without a vendor widget. I then instrumented the funnel through Shopify's closed checkout with a custom Web Pixel and found the layout shift PageSpeed had missed. Sales in the eight weeks after release were 45% above the eight weeks before. Absolute figures remain with the brand.
Reusable Liquid files across the theme and its templates, not a single page.
View main case study
The subscription offer designed and built end to end: plans, cadence per pack, a price that always matches the bill, no vendor widget.
Three silent cart failures that were quietly costing orders, traced to one root cause and closed.
A CLS of 0.9 on a third of mobile sessions that PageSpeed never surfaced, brought down to zero.
Selected Shopify work
From a medically complex catalog to a disciplined premium-theme adaptation, each project required a different balance of custom experience, native Shopify behavior, and merchant control.
Absolute Support
A custom product-selection and educational layer for a medically complex catalog, while Shopify's native variant, cart, search, and filtering systems remained the source of truth.
Boxwood Coffee
A disciplined Prestige adaptation for a specialty roaster spanning retail, subscriptions, two cafés, catering, and wholesale, with custom code reserved for coffee-specific data and navigation.
What I take on
From scratch, full redesigns, custom sections and templates, metafields on OS 2.0. Pixel-exact from Figma through the MCP pipeline.
Recharge, Loop, native Selling Plans. Custom subscription widgets when the vendor solution does not fit the design or misstates the price. Subscriber migrations with no double charges. Bundles, packs with live savings math, upsells, cross-sells, quiz funnels, product finders, comparisons, any custom buy box. I know which of these actually lift conversion and which are merely fashionable, and I say so plainly.
Subscription platforms, wholesale portals, POS, analytics, data migrations without loss.
I see where a customer drops off the path to purchase and remove it. Pixels, events and conversions across the whole funnel, checkout included: GTM and DataLayer, GA4 ecommerce, Google Ads and Meta Pixel, Amplitude, Klaviyo. Custom Web Pixels where the standard ones stop. I can own this stack end to end.
Measured on real users rather than in PageSpeed. My own field-data scripts show which metric degrades on which device, so the fix targets exactly that. On one store this surfaced a CLS of 0.9 for a third of mobile users that lab tools never saw, and brought it to zero.
Git with no lost content and no downtime. Several developers and a content team in the Customizer? I set up the process: branches per theme, isolated revertable PRs, clear rules for shared files. No one overwrites anyone else's work.
Policies, Markets, localization, legal pages. Everything a store needs to launch and stay up.
Commerce engineering
I work beyond the theme layer: mapping the purchase path, identifying where trust or commerce state breaks, adding the measurement needed to understand it, and changing the smallest part of the system that can improve it.
I trace the path from offer to order and find where the visible experience and commerce state stop matching.
Purchase path
Offer
Pricing, packs, savings
Product decision
Variants, subscription, education
Cart
State, quantity, drawer
Checkout
Events, delivery, payment
Order
Confirmation and follow-up
Common breakpoints
Stale pricing · Mismatched variants · Silent cart failures · Mobile instability · Missing events · Checkout gaps
I decide whether a requirement should be configured, extended, integrated, or built.
Configure
Use the platform where it already solves the requirement.
Extend
Adapt the native system with theme presentation and structured data.
Integrate
Connect apps and external systems without duplicating ownership.
Build
Add custom behavior only where the requirement genuinely needs it.
The goal is not maximum customization. It is the smallest reliable solution.
When existing analytics are insufficient, I add the instrumentation needed to observe, diagnose, change, and verify.
Observe
Real-user behavior and events
Diagnose
Find the root cause
Change
Implement the smallest useful fix
Verify
Measure the engineering outcome
Loop continues as new evidence appears.
RUM · Checkout Web Pixels · Browser verification · Operational checks
Every change is verified after release on the store's own data, not on a lab score.
A commercially useful improvement must also survive daily merchandising, app integrations, theme updates, and future releases.
Merchant ownership
Routine content remains editable.
Structured data
Products and collections carry their own information.
Safe delivery
Changes remain isolated and revertable.
Compatibility
Custom work respects the platform, theme, and installed apps.
A better storefront should not become a harder store to operate.
Send the task and the goal. From there I read the code, take the work through release and verify it myself. English at B2, direct work with US clients, no intermediaries.
Start a conversation
