Why Shopify Projects Run Over and How to Write a Scope

Most Shopify projects that run over time or budget were not badly built. They were badly described. The brief said "redesign the product page" and three weeks later the product page also needed a size guide, a new review layout, a sticky cart and a different image gallery, each one reasonable and none of them in the original estimate. This guide explains why Shopify projects overrun, and how to write a scope that holds, whichever way you are paying for the work.

It is written for founders and ecommerce managers commissioning Shopify work, not for developers.

Why do Shopify projects run over?

Almost always for one of five reasons, and only one of them is the developer being slow:

1. The scope described an outcome, not the work. "Make the store faster" or "improve the checkout" cannot be estimated, because the amount of work depends on what is found.
2. Decisions arrived late. Content, images, approvals and answers to questions are inputs to the project. When they arrive a week late, the timeline moves a week, and often the developer's schedule does not have that week free.
3. The store was more complicated than anyone said. Old code from removed apps, a heavily edited theme, or an integration nobody documented. These are discovered during the work, not before it.
4. Small additions accumulated. Each one was quick. Together they were a second project.
5. Nobody defined done. Without an agreed acceptance test, the last ten percent of a project stretches, because every review produces another round of changes.

The first, fourth and fifth are scope problems, and they are within your control before work starts.

What should a Shopify project scope include?

Enough that a developer who has never seen your store could estimate it, and enough that you could tell afterwards whether it was delivered. In practice:

• The pages and features affected, listed individually. "Product page, collection page and cart drawer" rather than "the storefront."
• What each one should do when finished, described as behaviour a person can check. "Shows the size guide in a popup from a link under the size selector" rather than "better size guidance."
• What is explicitly out of scope. This is the section people skip and the one that prevents most arguments.
• Designs or references, if the work is visual. A mockup, a screenshot of a store you like, or a sketch. Anything is better than a description of a feeling.
• Devices and browsers it must work on. For most Indian D2C stores, mobile first is not a preference, it is where the orders are.
• Apps and integrations involved, including the ones the work should not break.
• What you will provide, and by when: copy, images, product data, decisions, access.

What does a good scope look like in practice?

Here is a short example for a common job, adding a size guide and delivery estimate to a clothing store's product page. It is illustrative, not taken from a client project, but it shows the level of detail that lets a developer quote with confidence.

Pages affected: product page template for the "Apparel" product type only. Other product types unchanged.

Size guide: a "Size guide" link directly under the size selector opens a popup with a measurement table. Table content comes from a metafield per product type, so the team can edit it without a developer. Popup closes on tap outside and on the close button. Works on mobile and desktop.

Delivery estimate: a line under the add to cart button reading "Delivered in X to Y days", where X and Y are set per shipping zone in theme settings. No pincode lookup in this phase.

Out of scope: pincode based delivery dates, size recommendation quizzes, changes to collection pages, any change to checkout.

Must not break: the reviews app widget, the wishlist button, variant image switching.

We provide: size tables for five product types and delivery ranges per zone, before development starts.

Done means: works on the latest iOS Safari and Android Chrome, the product page loads no slower than before, reviewed on a preview theme and approved before publishing.

Notice what the out of scope line does. The pincode lookup is the obvious next request, and it is a much bigger piece of work. Naming it now turns a future argument into a future phase.

How do you describe work you cannot fully specify yet?

Split it. Some work genuinely cannot be scoped until someone looks: a speed problem, a bug with an unknown cause, a feasibility question about an integration. Pretending otherwise produces a padded estimate or an argument later.

The honest approach is a short first phase whose only output is a written scope for the second. Pay for the investigation on its own terms, then scope and price the fix once the cause is known. We explain how that fits the different ways of paying for work in our guide to fixed price, hourly and retainer billing.

How should changes during the project be handled?

Through a process agreed before the first one arrives. Changes are normal. A project where nothing changes is usually one where nobody looked closely at the work in progress. The problem is not change, it is change without a record.

A workable change process has four steps:

1. Write it down. One line in a shared list, not a comment on a call.
2. Estimate it. The developer says what it adds in time and cost, and whether it affects anything already built.
3. Decide. You approve it, defer it to a later phase, or drop it. Deferring is often the right answer, because it protects the launch date.
4. Track the total. The running list of approved changes is visible to both sides, so nobody is surprised by the final invoice.

A useful rule: anything that appears after the scope is agreed goes into a "phase two" list by default, and only comes into the current project if it is necessary for launch. Most items on that list turn out to be less urgent a month later.

What does "done" mean for a Shopify project?

An agreed list of checks that the finished work passes, written before development starts. For example:

• Every item in the scope works as described, on the agreed devices.
• Existing features the work touched still behave as before: cart, checkout, filters, search, apps.
• Pages affected load no slower than they did before the change, measured the same way.
• Nothing is published to the live theme until you have reviewed it on a preview.
• A short note lists what was changed and which theme files were edited.

Agree too how long you have to report problems after launch, and what counts as a defect versus a new request. A button that does not work is a defect. A button you would now like in a different colour is a change.

What will a developer need from you before starting?

Access, content and a decision maker. Access should be through a collaborator account rather than your own login, with only the permissions the work needs. Content should be ready before the work that depends on it is scheduled, not promised for later. And one named person on your side should be able to approve changes and answer questions within a day, because a project waiting for answers is a project running over.

Back up the theme and your product data before any work begins, and ask your developer to work on an unpublished copy of the theme. Shopify's own theme duplication guidance recommends a backup copy before any customisation. Both cost nothing and turn a bad change into an inconvenience rather than an incident. We describe the routine in our guide to updating a customised theme safely.

How do you check a quote against your scope?

Line by line. Every item in your scope should appear in the quote, with any assumption the developer made written next to it. Items in the quote that are not in your scope deserve a question, and items missing from the quote are the start of the overrun you are trying to avoid.

If a quote comes back as a single number with no breakdown, ask for one. A developer who has actually read your scope can say how the estimate splits across it. We go through what else to look for in our guide to reading a Shopify quote.

Want your scope reviewed before you send it?

Free scope review. Get in touch or email hello@exactwhy.com with the subject "Scope review" and your brief attached. We reply within 4 hours with what is missing, what cannot be estimated yet, and the questions a developer will ask you anyway.

Paid discovery. For larger projects, we run a short discovery on your store and deliver a written scope you can take to any developer, including us.