The most common complaint I hear from store owners about past developers is not that the work was bad. It is that the work was a black box. The store launched, the invoice was paid, and six months later nobody on the team could change a banner without emailing someone who had moved on.
A good Shopify project ends with a handover, not just a launch. This is the checklist I work from, and it is what you should ask any developer for before you sign.
Why handover matters more than launch
Launch is a moment. Running the store is the next five years. If your team cannot operate the store confidently, every marketing idea becomes a ticket, every seasonal change costs money, and the store slowly drifts back toward falling behind.
A developer who builds for handover works differently from one who builds for launch. They put controls in the theme editor instead of hardcoding values. They name things clearly. They document decisions. They assume someone else will maintain the store, because someone else will.
The handover checklist
1. Every section editable in the theme editor
This is the big one. Any content that marketing might want to change, including headlines, images, buttons, colors, spacing, product selections and visibility, should be a setting in the theme editor, not a value buried in Liquid.
Ask your developer to demonstrate changing each custom section's content without touching code. If they cannot, it is not finished. The Shopify customizer is the whole point of the platform for non-technical teams, and a theme that ignores it is a liability.
On the S9 Digital projects, the client specifically called out that comments and options in the customizer meant non-technical staff could update the store. That is the standard.
2. Sections with sensible defaults and clear labels
A section with forty settings and cryptic names is almost as bad as no settings. Each setting should have a plain-English label, a short help text where the intent is not obvious, and a default that looks good out of the box. Group related settings with headers.
3. A duplicate theme for safe editing
Your live theme should never be the one anyone experiments on. The developer should leave you with a clear workflow: duplicate the live theme, make changes on the copy, preview, then publish. Write it down in the handover document.
4. A short written guide
Not a manual. A two to five page document covering: what each custom section is for and where it is used, how to perform the five most common tasks (change the homepage hero, add a promo bar, feature a collection, update the shipping message, swap a product's badge), anything unusual about how the theme works, and who to contact if something breaks.
Loom-style screen recordings for the common tasks are even better.
5. A handover walkthrough
A live session where the developer walks your team through the store, performs the common tasks, and answers questions. Record it. The people who need it most are often not the ones who were on the project calls.
6. Access handed back properly
Collaborator access should be scoped to what the developer still needs, or removed entirely when the engagement ends. Any third-party accounts created during the project (fonts, apps, services) should be in your name, on your payment method, with you as the owner. Check this before final payment.
7. The code in version control
Your theme should live in a Git repository you own, connected through Shopify's GitHub integration or at minimum exported and stored somewhere safe. If the developer vanishes tomorrow, you should have everything. If the next developer joins, they should be able to see the history.
8. A performance baseline
Lighthouse scores on mobile for the homepage, a collection page and a product page, recorded at launch. This is your reference point. When someone installs an app six months from now and the store gets slower, you will know. Our speed guide explains how to run these.
9. A list of what was deliberately left out
Every project has things that were discussed and not built, either for scope or because they were not yet needed. A short list of those, with the reasoning, saves the next developer from rediscovering the same decisions and helps you plan the roadmap.
10. Clarity about what happens next
Is the developer available for small changes? At what rate? With what turnaround? Or is this a clean handoff? Either is fine, but it should be explicit. The worst outcome is a store owner who assumes support is included and a developer who assumes the project is closed.
Red flags during the project
You do not have to wait until launch to know whether the handover will be good. Watch for these during the build.
Hardcoded content. If you ask for a headline change during the project and the answer is "I will update the code," ask why it is not a theme setting. Occasionally there is a good reason. Usually there is not.
No preview theme. If the developer is working directly on your live theme, or you only ever see screenshots rather than a preview link, the workflow is not set up for safe changes later.
Undocumented decisions. If you ask why something was built a certain way and nobody can tell you, that knowledge will leave with the developer.
Reluctance about Git. Any professional Shopify developer should be comfortable putting your theme in a repository you own. Hesitation here is a sign the project is being treated as disposable.
Scope conversations that never mention handover. If the quote describes pages and features but says nothing about training, documentation or editor controls, add them before you sign.
None of these are reasons to end a project on their own, but together they predict a store you will not be able to run.
What to ask for before you sign
Put the handover in the scope from the start. Specifically, ask the developer:
- Will every custom section be fully editable in the theme editor?
- Will I get a written guide and a recorded walkthrough?
- Will the theme be in a Git repository I own?
- What is your process for making changes after launch, and what does it cost?
- Will you leave Lighthouse scores at launch so I have a baseline?
A developer who builds for handover will answer these easily. One who hesitates is telling you something about how the project will end.
How I do it
Every project I run is fixed scope and fixed price, and the handover is part of the scope. You see progress weekly, not at the end. At launch you get the walkthrough, the guide, the repository and the baseline. After launch, you can hand the store to your team, or keep me on a growth retainer so the backlog keeps moving. Either way, you are never dependent on me to change a banner.
If you have a store that was launched without a handover and your team is stuck, that is fixable too. A short project to add theme-editor controls to existing sections and document the store is often the most cost-effective work a store owner can commission. Start a quick chat and tell me what your team cannot do today. Or start with the free store audit, which will flag the parts of your theme that are hardcoded and holding you back.
A store you cannot run is a store that will fall behind. Ask for the handover.
About the author
Nick Perry
Nick builds, fixes and grows Shopify stores for owners who are done falling behind. Shopify Select Partner, 200+ projects since 2017, and every number on this site comes from a real store.