Scope the work
What's changing, what stays, and where tracking needs to be considered from the start.
Development
Shopify Development
Theme changes, checkout customisation and app integrations, built by the same people who will later have to make your pixels fire correctly on top of it.
0
Pixels broken by the build after launch
3–6wk
Typical theme & checkout build timeline
1
Team building the store and the tracking
The problem
Most Shopify builds and Shopify tracking are done by different people
Checkout Extensibility changed what a theme can touch and when a script can run. A developer who doesn't think about tracking will happily ship a custom checkout step that quietly breaks every pixel downstream — because nobody told them it mattered.
We build the store and the tracking as one piece of work, so the launch doesn't come with a second project to fix what the first one broke.
The fix
What we build
- Theme development and customisation, on Online Store 2.0 or headless
- Checkout Extensibility: custom fields, upsells, post-purchase pages
- App and API integrations, without duplicating what your CRM already knows
- Page speed work, since Core Web Vitals affect both Ads Quality Score and conversion rate
- Migration from an existing theme or platform without losing SEO equity
- Built with the tracking rebuild in mind from day one, not bolted on after
Before & after
What changes once tracking is part of the build
The same checkout, built once instead of built twice — the second time to fix what the first launch broke.
Tracking added after launch, as its own project
The store ships, then a separate team is called in later to work out why the pixels never fired correctly on the new checkout.
Before
Bolted on after launch
After
Built in from day one
Checkout Extensibility scripts break pixels silently
A custom checkout field or upsell step ships fine on its own, and quietly stops a conversion event from ever firing.
Before
Breaks silently
After
Tested against tracking
Migrations lose SEO equity and tracking history
A theme or platform migration done without a plan for redirects and historical tracking data quietly resets years of accumulated equity.
Before
Rebuilt from scratch
After
Migrated without losing equity
Process
How a build runs
Build on a dev store
Theme, checkout and app work done in isolation, reviewed before it touches production.
QA against real journeys
Checkout, upsells and edge cases tested, including how they interact with tracking.
Launch and document
Migrated to production with a written record of what changed and why.
What clients say
Don't just take our word for it
Clear scope, clear finish line, no drifting retainer. The handover documentation was good enough that our own team could pick it up.
Search terms get read by an actual person every week. The list of things we were paying for and did not want was longer than I expected.
They were upfront that a perfect match between the platform and our books was never going to happen. What we got instead was a small gap they could explain.
Questions
Common questions
Do you work with our existing theme, or only custom builds?
Both. Plenty of engagements are targeted changes to an existing theme rather than a full rebuild.
Can you also fix our tracking as part of this?
Yes — most Shopify builds we run are paired with the Shopify tracking & attribution setup, since the two are easiest to get right together.
Do we need to move hosting or apps to work with you?
No. We work within Shopify's platform and your existing app stack, and only recommend changes where something is actually causing a problem.
How long does a typical build take?
Most theme and checkout builds run 3–6 weeks depending on scope, with QA against tracking built into the timeline rather than added at the end.
Start here
Find out what your account is actually reporting
Send us access and we will come back with a written audit: what is tracked, what is double-counted, what is missing, and what we would change first.
No pitch deck · No lock-in · Findings are yours either way