# Shopify Project Scoping: Estimate Without the Overrun

> A shopify project scoping process for agencies: what to nail down before quoting, where estimates go wrong, and how discovery depth drives quote accuracy.

_Published: 2026-07-31 · CommerceCopilot_

## Why Shopify estimates go wrong before anyone writes code

Every agency owner has quoted a project that looked straightforward and turned into a loss. The client wanted "a redesigned product page and a faster checkout." The quote went out. Six weeks later the project is still open, the team has burned through the margin, and nobody can name the exact moment it went wrong, because it went wrong in a dozen small moments: an integration nobody checked before pricing, a stakeholder who joined late with a different opinion, a "quick addition" that turned into three days of work.

A shopify project scoping process exists to stop that pattern before it starts. Scoping is not discovery, and it is not writing a proposal. It is the specific act of turning what you learned in discovery into a defined set of deliverables, a timeline, and a number, and it is only as reliable as the information underneath it. Get the process right and your estimates hold. Get it wrong and every project becomes a negotiation with your own margin.

## What a project scoping process is actually deciding

Scoping answers four questions, in order: what are we building, what does it depend on, how long will it take, and what will it cost. Agencies that struggle with estimates usually skip straight to the fourth question, because clients want a number and salespeople want to close. But a price attached to an undefined scope is a guess with a decimal point, not an estimate.

The agencies that scope well treat the first two questions as the real work. "What are we building" needs to be specific enough that a developer could start from it without a follow-up call: which pages, which flows, which edge cases are in and which are explicitly out. "What does it depend on" means checking the client's current theme, apps, and data before committing to anything, because a redesign that sounds like two weeks of front-end work can hide an undocumented third-party API or a data migration nobody scoped because nobody asked.

## Where estimates go wrong

A handful of failure patterns account for most of the overruns agencies see.

**Quoting before the technical check.** Pricing a project off a client's description of what they want, without checking their current theme, apps, and integrations, means the estimate is built on assumptions instead of facts. The most common surprise is an app or custom code layer the client didn't think to mention because they don't think of it as part of "the project."

**Treating the brief as the full scope.** A client brief describes an outcome, not a build. "Improve mobile conversion" is a goal. It is not a list of what gets built, and scoping directly from the brief without a translation step means every ambiguity in the brief becomes an ambiguity in the price.

**No line between what's confirmed and what's assumed.** Some parts of a scope are locked: the client has approved them, or they are simply fixed platform constraints. Other parts are assumptions your team made to keep the discovery moving. If the quote doesn't distinguish between the two, an assumption that turns out wrong becomes an unplanned change instead of a flagged risk.

**No process for handling new information.** Clients keep learning what they want throughout a project, not just before it starts. Scoping that treats the signed quote as the end of the conversation, rather than the current version of a plan that can be revised, turns every legitimate new requirement into a fight about whether it's "in scope."

Research on project delivery backs up how common this is outside Shopify too: PMI's Pulse of the Profession research found that 52 percent of projects experienced scope creep or uncontrolled changes to scope in a recent 12-month period, up from 43 percent five years earlier. Uncontrolled scope change is not a rare failure mode. It is closer to the default outcome for teams that don't have a defined process for handling it.

## The scoping process, step by step

### 1. Scope only what discovery has resolved

Discovery and scoping are sequential, not parallel. If your [discovery process](/blog/shopify-agency-client-discovery-process) hasn't yet established the platform, the core pages or flows in scope, the integrations, and the client's definition of done, you don't have enough to scope accurately, no matter how much pressure there is to send a number. Shopify's own partner guidance frames this directly: discovery reduces the risk of budget overruns by giving the team what it needs to build a realistic estimate, and an estimate set before that groundwork is done is set against guesswork, not a known scope.

### 2. Separate confirmed scope from assumptions

As you translate discovery findings into a scope document, mark every item as either confirmed (the client signed off, or it's a fixed platform fact) or assumed (your team's best read on something that wasn't explicitly settled). This single habit changes how change requests get handled later. When an assumption turns out wrong, it's a flagged risk that was already priced with some buffer. When it's treated as confirmed and turns out wrong, it's a surprise that eats margin with no cushion.

### 3. Price the unknowns, not just the knowns

Every scope has a confident core and a fuzzy edge. The confident core, pages and features you can describe precisely, prices reasonably accurately. The fuzzy edge, the parts still resting on an assumption, carries the real risk. Rather than pricing the whole project at one flat confidence level, price the confident core tightly and treat the fuzzy edge as a named risk with its own line, even if that line is just a note in the internal estimate: "checkout customization scope depends on confirming Shopify Payments vs a third-party gateway, currently assumed as Shopify Payments." That note is what turns a surprise into a conversation you saw coming.

### 4. Match the pricing model to how settled the scope is

Fixed price and time and materials aren't just billing preferences; they're a response to how much of the scope is actually known. A fixed-price quote asks your agency to absorb the risk of anything the scope got wrong, which only makes sense when the scope is well-bounded and the technical check is done: a defined migration, a checkout redesign, a store launch. Time and materials shifts that risk back to the client in exchange for flexibility, the more honest model when scope is still evolving or discovery surfaced open questions that won't resolve before work starts. Quoting fixed price against a still-fuzzy scope is how agencies end up eating the gap between what they estimated and what the client needed.

### 5. Build the change process into the quote, not around it

Scope will change. Projects that stay profitable aren't the ones that prevent every change; they're the ones with a defined, unsurprising way to handle it. Before work starts, agree with the client on what happens when a new requirement surfaces: how it gets evaluated, who decides if it's in or out, and how it affects timeline and price. Put that process in the proposal itself, not just in your team's head, so it's a known step instead of an awkward negotiation.

## A scoping checklist

- Confirm platform, current theme, apps, and integrations before pricing, not after.
- Translate the brief into specific deliverables; a goal is not a scope.
- Mark every scope item as confirmed or assumed, and keep that distinction visible in the estimate.
- Price the confident core and the fuzzy edge differently instead of one flat number.
- Choose fixed price only when the technical check is done and the scope is genuinely well-bounded; default to time and materials when it isn't.
- Write the change process into the proposal before the first change request arrives.

## Where scoping accuracy actually comes from

The quality of a scope is a direct function of the discovery underneath it, and discovery that stops the moment a quote goes out misses everything the client learns about their own project afterward. CommerceCopilot's Business Analyst agent treats discovery as continuous rather than a single pre-quote phase: it keeps listening across notes, connected Slack channels, and meeting transcripts, and flags an open question the moment something is unclear instead of quietly assuming an answer. That matters most at the scoping stage, where an unflagged assumption is exactly what turns into an unplanned change order six weeks in. The [discovery project guide](/docs/your-first-discovery-project) covers how it builds that living model and turns it into sequenced tickets once the scope is settled enough to build from, which is also where [writing tickets a team can actually build from](/blog/how-to-write-development-tickets) picks up.

## FAQ

### How much discovery does a project need before you can scope it?

Enough to name the platform, the core pages or flows in scope, the integrations, and the client's definition of done. A small storefront update might reach that bar in a single structured session. A larger build, especially with multiple integrations or several stakeholders, usually needs more. The goal isn't a fixed amount of discovery time; it's reaching the point where the open questions left are ones you can price as risk rather than ones that would change the shape of the estimate entirely.

### Should every project use the same pricing model?

No. Fixed price fits a well-bounded scope where the technical check is already done: a defined migration, a checkout redesign, a scoped feature build. Time and materials fits work where the scope is still evolving, or where discovery surfaced dependencies that won't be fully resolved before the work needs to start. Applying the same model to every project regardless of how settled the scope is tends to either overprice simple work or underprice risky work.

### What's the single biggest cause of blown Shopify estimates?

Quoting before checking the client's actual technical environment. A description of what a client wants and a technical assessment of what exists are two different inputs, and pricing off only the first is the most common way a reasonable-sounding project turns unprofitable. The fix isn't a longer discovery process for its own sake; it's making sure the technical check happens before the number goes out, not after.

### How do you handle a client who wants a number before discovery is done?

Give a range, not a fixed number, and explain what it's conditional on. A range tied to specific open questions ("$18,000 to $26,000, depending on whether the loyalty integration uses the existing app or requires custom API work") beats a false-precision number that has to be walked back later, and it sets up the change conversation in advance instead of after the client has anchored on a figure that never had a solid scope behind it.

---
Canonical page: https://www.commercecopilot.ai/fr/blog/shopify-project-scoping