Most developer work on a Shopify store doesn't fail in the code. It fails in the message that asked for it.
"Can you fix the size chart on mobile?" sounds clear until the developer says it's done and the founder says it isn't. Nobody wrote down what done meant.
This is the developer brief system I'd run. It comes from the operations setup plan I've written about, where developers get written briefs with clear "done" criteria and their work is tested before sign-off.
Table of contents
The problem: requests, not briefs
In a small brand, developer requests arrive from everywhere. A founder in a voice note, marketing in a DM, support forwarding a customer screenshot.
Each request leaves out something: which pages, which devices, what counts as fixed. The developer fills the gaps with guesses, and the brand pays for the guesses twice.
Then the change goes live without anyone testing it on a real order. That's how a theme fix quietly breaks a checkout button or a product option.
How the system is put together
Six parts: one way in, the brief, the done criteria, safe access, a test before sign-off, and who owns what.
Part 1: one way in
Every developer request goes to the operations manager first, not to the developer. Ops turns it into a brief and adds it to the task tool with one owner and a due date.
Anything that spends money or changes priorities goes to the founders first, with options and costs, as the setup plan's ground rules say.
Part 2: the brief
One page, the same headings every time: what is wrong or wanted, why it matters to the business, where it happens (pages, devices, markets), what is out of scope, the deadline, and who signs off.
Screenshots and an example order or product link go in the brief, not in a chat thread.
Part 3: "done" criteria
The Scrum Guide describes a Definition of Done as a shared, formal description of the quality a piece of work must meet before it counts as finished. I borrow that idea for every brief.
Each brief lists three to five checks anyone can test, written as plain sentences. For example: "On iPhone and Android, the size chart opens from every product page in the Tops collection." Done means every check passes, not "I pushed it".
A standing list sits under every brief too: tested on mobile, tested with a real order where checkout or orders are touched, and nothing else changed on the page.
Part 4: safe access
Developers get collaborator access, not a shared login. Shopify's developer docs say the merchant finds a collaborator request code under Settings, Users, Security, and approves or rejects each request. The merchant controls which parts of the store a collaborator can reach.
Theme work happens on a duplicate theme. Shopify's help page recommends duplicating a theme as a backup copy you can go back to. Note the 20-theme limit per store, so old copies need clearing out.
The docs also say collaborator access expires when nobody from the developer's organization logs in for 90 days. I'd still review the access list monthly rather than rely on that.
Part 5: test before sign-off
When the developer says it's ready, ops runs every done check on the duplicate theme or in the live store as agreed. Anything that fails goes back with the check that failed, not a new description of the problem.
Only after every check passes does the named sign-off person approve publishing. The brief is then marked done and linked from the change log.
Part 6: what is automatic and what a person does
Automatic: very little, on purpose. The task tool's due-date reminders, and an overdue item showing up in the exceptions tracker review.
A person: writing the brief, agreeing the done criteria with the developer before work starts, testing, signing off, and managing access.
Ownership: operations owns the brief and the testing. The developer owns the build. One named person, usually a founder, owns sign-off. Open briefs and anything blocked go into the Friday founder update.
What it solves
"That's not what I meant." The done checks are agreed before work starts, so both sides judge the same thing.
Paying twice. Fewer rounds of rework from guessed requirements.
Broken live store. Work is tested on a copy and against real orders before it reaches customers.
Loose access. No shared passwords, and a regular review of who can get in.
No history. Every change has a brief explaining why it was made and who approved it.
The effect on the business, and how to measure it
I'm not quoting results here. I don't have published numbers for this system, and I won't invent them.
The target is that every developer task has a written brief with done checks before work starts, and nothing goes live untested. That is a target, not a result.
Here is what I'd baseline before rolling it out, and compare after.
Rework rounds. How many times a task goes back to the developer before sign-off.
Time to done. From brief to sign-off, by task size.
Live issues after release. Bugs or support tickets traced to a recent change.
Briefs with done checks. The share of developer tasks that had them before work started.
Developer hours per task. If you pay hourly, compare billed hours on similar tasks.
Where it shows up in the business: lower developer spend, fewer conversion problems from untested changes, and fewer founder hours spent explaining the same request twice.
The bigger picture: developers are one of the six groups
In the operations setup plan, developers are one of six groups around the operations hub. Each group gets one clear way of working with ops, and for developers that is the brief.
The same habit runs through the other systems: one owner, a date, and a written record. The exceptions tracker does it for order problems. The Friday update does it for founders.
With more changes coming to Shopify every week, like Flow buying labels or batch fulfillment, a clear brief is also how you hand a developer a new feature safely.
Rollout checklist
- Agree that every developer request goes through operations first.
- Write the one-page brief template with fixed headings, including out of scope and sign-off.
- Write the standing done checks that apply to every task.
- Name one sign-off person for developer work.
- Move every developer onto collaborator access and remove any shared logins.
- Make duplicating the live theme the first step of any theme task.
- Test against the done checks before every publish, including a real order when checkout or orders are touched.
- Review the collaborator access list and old theme copies monthly.
- Baseline rework rounds, time to done and post-release issues, and review them monthly.
A good developer can build almost anything. The brief is what makes sure they build the thing you meant.
Source: method from the Scrum Guide's Definition of Done. Tool details checked against Shopify's developer docs on collaborator access and request codes and the Shopify Help Center page on duplicating themes. The system design and the expected effects are my own operator view, based on my operations setup plan.
Frequently asked questions
What should a developer brief include?
What is wrong or wanted, why it matters, where it happens, what is out of scope, the deadline, who signs off, and three to five done checks anyone can test.
What does "done" mean in this system?
Every done check in the brief passes when someone other than the developer tests it, and the named sign-off person approves it. It borrows the Scrum Guide's idea of a shared Definition of Done.
How should a developer get into my Shopify store?
Through collaborator access, which you approve with a request code from Settings, Users, Security. You control which parts of the store they can reach, and access expires after 90 days without a login from their organization.
What should I measure?
Rework rounds per task, time from brief to sign-off, issues after release, the share of tasks with done checks, and developer hours on similar tasks.