How to Work With a Shopify Development Expert: Brief, Scope, Contract and Handover (2026)

Hiring is the easy half. Most Shopify projects that go wrong were staffed with a perfectly good expert and then run badly: a vague brief, a scope that grew every week, a contract that said nothing about who owns the theme, and a launch nobody had defined. This guide is about the working relationship after the handshake. If you are still choosing, start with when to hire a Shopify agency and how to hire and vet a Shopify developer; if you want to know how to find candidates, the Shopify Partner Directory guide covers that. Here we assume the expert is chosen and the question is how to get a good store out of them.

Step 1: the brief, one page, written by you

A Shopify development expert can estimate a brief; they cannot estimate a feeling. Before the first call, write a single page with five headings and keep it under 500 words:

• What the business does and sells, with the three products that make most of the revenue. Catalogue size, variants, whether you sell B2B or in more than one country.
• What is wrong today. Not “the site feels old” but “mobile conversion is half of desktop”, “the theme breaks when we add a video”, “we cannot launch a collection without a developer”.
• What done looks like. Three measurable outcomes: a page speed target, a conversion metric, a workflow (“marketing publishes a landing page without a ticket”).
• Constraints. Launch date and why, budget range, apps that must stay, integrations that must keep working (ERP, email, subscriptions), brand guidelines.
• What is out of scope. Say it explicitly: no migration, no new logo, no copywriting. The out-of-scope list is what stops the estimate doubling later.

Attach the store URL, access to Shopify admin as a collaborator (never share the owner login), your analytics, and the current theme name. A good expert will come back with questions; a great one will come back with questions you did not think of.

Step 2: scope and estimate, in writing, with assumptions

The estimate you accept should list what will be built, page by page or feature by feature, and the assumptions behind the number: which theme it is based on, how many templates, which apps are integrated, whether content and images are supplied by you, how many rounds of design feedback are included. An estimate without assumptions is a guess you will pay for twice.

Ask for the estimate in one of the three shapes we use ourselves, because each fits a different kind of work: a fixed price when the scope is clear and finite (a theme build, a migration); time and materials when the work is exploratory or the scope will be decided as you go (integrations, performance work, a redesign in stages); an on-demand retainer for continuous improvement after launch. As an example of what scope does to price, a Shopify migration project at Mgroup typically ranges from $8,000 to $50,000 or more depending on the platform and catalogue size. The same range applies to almost every kind of Shopify work: the number is a function of the scope you wrote down in step 1.

Step 3: the contract, and the six clauses that matter

Most Shopify contracts are short, and that is fine. Six things must be in it regardless of length:

1. Ownership. You own the theme code, the custom app code and the design files on final payment. The expert may keep reusable libraries, but your storefront is yours.
2. Access. Work happens under a collaborator or staff account you control and can revoke. Custom apps are installed on your Partner or store account, not the expert’s.
3. Milestones and payment. Deposit, milestone payments tied to deliverables you can see (a staged theme, a working integration), and a final payment on launch. Never pay 100% up front, never withhold 100% to the end.
4. Change requests. How new requests are priced and approved. A one-line process (“written request, estimate, your approval, then work”) prevents the quiet scope growth that kills timelines.
5. Acceptance. What “done” means: the outcomes from your brief, a QA checklist, a browser and device list. Acceptance is what you sign, not a feeling on launch day.
6. Warranty and support. A defined period after launch for defects at no charge (30 days is common), and what happens after: retainer, hourly, or nothing.

If the expert works through a marketplace or the Partner Directory, the platform’s terms sit on top of this; they do not replace it.

Step 4: kickoff and the working rhythm

One kickoff call sets the pace for the whole project. Agree on the tools (a shared board, one chat channel, one place for files), the cadence (a weekly demo of working software beats a daily status message), who on your side can make decisions, and what a “blocker” is and how quickly each side answers one. Decide the staging setup: a duplicate theme in your store for theme work, a development store for app work, and a rule that nothing is published to the live theme without your sign-off.

Then get out of the way between demos. Experts do their best work in uninterrupted blocks; the weekly demo is where you steer.

Step 5: design and build, what to check at each demo

• Design stage. Check the mobile version first, because that is where most of your visitors are. Check that every element the merchant team edits later is a section or block setting, not hard-coded. Check that the design uses your real products and real copy, not placeholders, or you will approve a layout that breaks with your actual content.
• Build stage. Ask to see the theme editor, not only the storefront: can your team change the homepage, add a collection banner, swap a promo bar, without a developer? Ask which apps are integrated and see them working. Ask for a Lighthouse or PageSpeed result on the staged theme and compare it with your live store; if the new theme is slower, stop and ask why.
• Integration stage. Test with real data: a real order through a test gateway, a real product sync from the ERP, a real email from the flow. Fake data passes tests that real data fails.

Step 6: QA and launch

Before launch, run the acceptance checklist from the contract together. At minimum: every template on mobile and desktop in the browsers you listed; the checkout with each payment method; discount codes; search and filters; every form; analytics and pixels firing; 301 redirects if URLs changed; structured data and metadata in place; Core Web Vitals on the key templates. Our Shopify store testing checklist is the long version. Launch on a quiet day, keep the old theme unpublished but intact for a fast rollback, and have the expert on call for the first 48 hours.

Step 7: handover, so you are not dependent forever

A handover is not a zip file. Ask for: the theme and app repositories with commit history; a short document describing custom sections, metafields and any non-obvious settings; a list of apps with the account that owns each; credentials transferred to your accounts; a recorded walkthrough of the theme editor for your marketing team. Then decide the after-launch relationship on purpose: a retainer for ongoing work, an hourly arrangement for occasional fixes, or a clean end. Any of the three is fine; drifting into the fourth, where you email the expert when something breaks and hope, is how stores decay.

How the engagement shape changes the rhythm

• Fixed price. The scope document is the contract. Your job is change control: every new idea goes through the written change-request step, and you decide whether it is worth the extra cost or belongs in phase two. Demos check the deliverable against the scope, not against new ideas.
• Time and materials. Set a monthly budget cap and ask for a weekly burn report: hours used, what they produced, hours remaining. The risk on T&M is not dishonesty, it is drift; a weekly number keeps both sides honest about priorities.
• Retainer. Keep a prioritized backlog you own, agree response times for urgent issues, and review the backlog monthly. A retainer without a backlog turns into reactive firefighting and nobody can say what the money bought.

A sample milestone plan for a theme build

Timelines vary with scope, but the shape of a well-run theme project is stable, and each milestone is something you can see and sign:

1. Discovery. Brief review, store and analytics audit, app inventory, technical findings. Deliverable: the scope and estimate with assumptions.
2. Design. Mobile and desktop designs for the key templates with real products and copy. Deliverable: approved designs and a list of editable sections and settings.
3. Build. Theme built on a duplicate, section by section, demoed weekly in the theme editor. Deliverable: a staged theme your team can edit.
4. Integrations and content. Apps connected, metafields populated, content migrated or entered. Deliverable: the staged store with real data.
5. QA and acceptance. The checklist from the contract, run together. Deliverable: signed acceptance and a launch plan.
6. Launch and warranty. Publish, monitor for 48 hours, fix defects under warranty. Deliverable: the handover package and the after-launch agreement.

Tie a payment to milestones 1, 3, 5 and 6 and the money follows the work.

Red flags during the engagement, not only before it

• Work is happening on the live theme “to save time”.
• Custom apps are installed from the expert’s Partner account with no plan to transfer them.
• Estimates keep changing without a written change request.
• Demos show screenshots, not working software.
• The staged theme is slower than the theme it replaces and nobody can explain why.
• Questions get answered with “trust us” instead of “here is why”.

None of these means the expert is bad; all of them mean the process is, and process is the part you control. If you want a second opinion on a brief, a scope or a contract before you sign, our Shopify tech audit and consulting service does exactly that, and we are happy to say when the expert you already have is the right one.