/ 02 - Service
Shopify engineering,
built around the problem you actually have
A new store, a custom theme, a private app, or one feature that has never worked properly. The work is scoped to the problem, not to a package.
What you get before anything is built
Nothing gets built until it is written down
Every engagement starts with a written scope: what is being built, what it touches, what it does not touch, and what "done" looks like. It exists so that neither of us is discovering the requirements halfway through the build.
- What is being built the feature, template, app or store, described in behaviour rather than in technology.
- What it touches the theme files, apps, integrations and data that the change reaches, so nothing breaks quietly.
- How it is verified the specific checks that decide the work is finished, agreed before the work starts.
- What is out of scope written explicitly, because the things left out are what turn a build into an argument.
The scope is short. If it needs five pages, the problem has not been understood yet.
Three patterns, in almost every store
The build is rarely the actual problem
The theme was chosen for how it looks empty.
Templates are evaluated on a demo store with eight products and no reviews, no badges, no variant swatches and no long titles. The real catalog then breaks the layout it was picked for, and the fix is treated as a design preference rather than a defect.
Apps were installed to solve problems the theme created.
Each one injects its own scripts, its own styles and its own render-blocking calls. Nobody removes the app that the last app made redundant, and the storefront ends up carrying four solutions to two problems.
The product page is a specification sheet, not a decision aid.
Everything a buyer needs in order to say yes is present somewhere on the page, in the order the data happened to arrive rather than the order the decision is made. This is the single most common thing found, and it is almost always cheaper to fix than to rebuild.
Engagement
Scoped work, not retained hours
Work runs as a defined build against the agreed scope, with a working preview to look at rather than a status update to read. Changes to the scope are possible and are written down when they happen, so the finish line stays visible.
- You see it running, not described. Review happens on a live preview, not in a document.
- Changes are re-scoped, not absorbed. A new requirement is a new line, agreed before it is built.
- It ends. The engagement closes against the verification checks in the scope. Anything after that is a new piece of work.