# What Is Project Discovery for a Shopify Agency?

> Project discovery turns a vague client ask into a scope you can quote and build from. Here is what it actually is, and why it decides the price.

_Published: 2026-09-02 · CommerceCopilot_

## The short answer

Project discovery is the work that happens between a client's first ask and the quote you send back. It takes something true but not actionable, "we want the site to feel more premium," "checkout is losing people on mobile," "we need a loyalty program," and turns it into a scope specific enough to price, staff, and schedule. Shopify project discovery is not a formality before the "real" project starts. It is the phase that determines whether the number in your quote reflects what the project will actually cost, or a guess wearing a number.

Skip discovery, or compress it into a rushed intake call, and the cost does not disappear. It moves downstream, into change orders, scope disputes, and a developer building against assumptions nobody checked.

## Why discovery decides the quote

A quote is a bet on how much work a project will take. That bet is only as good as what you knew when you made it. If discovery surfaced the client's actual constraints (their current theme, their app dependencies, the stakeholder who has not signed off yet, the integration nobody mentioned until week three) the quote reflects reality. If discovery was skipped or rushed, the quote reflects whatever the sales conversation happened to cover, which is rarely the same thing.

This is why two projects that look identical at the pitch stage, same rough budget, same general ask, can produce completely different outcomes. One agency did the discovery work: confirmed the platform, mapped the integrations, got the decision-maker's actual definition of done. The other agency took the brief at face value and priced off it. The first project runs close to plan. The second one drowns in "actually, I meant" requests that everyone experiences as scope creep but that were really just unasked questions from before the contract was signed.

## What discovery actually produces

Discovery is not a call, or even a series of calls. It is a specific set of outputs, and a project is not ready to quote until they exist:

- **A confirmed platform and stack.** What the client is on now, what they are moving to, and what apps or custom code already depend on it.
- **A stated outcome in the client's words.** Not "redesign the site," but what changes for the business if the project succeeds, mobile conversion, checkout abandonment, a specific revenue target.
- **A list of constraints.** Budget range, hard deadlines, non-negotiable systems (Shopify Payments, a specific ERP integration, an existing loyalty app that has to stay).
- **A named decision-maker**, and ideally confirmation that the person in the discovery call actually has authority to sign off on scope.
- **Open questions, documented as open**, rather than quietly assumed one way and discovered wrong later.

None of that requires a long process. A straightforward storefront update can clear all five in a single structured conversation. A multi-stakeholder rebuild with several integrations needs more than one session to get there honestly. The list is the same either way; only the time it takes to fill it in changes.

## Where discovery breaks down

Three patterns show up again and again in agencies that treat discovery as a step to get through rather than an output to produce.

**The quote goes out before the technical check.** Committing to a price before confirming the client's current theme, apps, and data is the single most common way a scope goes wrong. The commercial conversation and the technical assessment need to happen before the number is final, not after.

**Findings live in someone's head or a Slack thread.** A stakeholder mentions a constraint on the kickoff call. Three weeks later, a different stakeholder says something that contradicts it, and nobody notices, because no one owns reconciling the two. Discovery that is not written down somewhere everyone can see is discovery that will not hold up past the second week.

**Discovery happens once and gets treated as permanent.** Real projects do not stay still. New requirements arrive on a Slack thread, a stakeholder who missed the original session joins a later meeting with a different priority. If your discovery output is a document nobody reopens, that new information either gets lost or turns into an unplanned change order, when it should have been folded back into the plan.

## Discovery, scoping, and the business analyst role

These three terms get used interchangeably, and the overlap causes real confusion. Discovery is the process of finding out what the client actually needs, including the parts they have not articulated yet. Scoping is what happens next: turning that understanding into defined deliverables, a timeline, and a price. A business analyst, whether that is a dedicated hire or [a role your agency currently splits across a few people](/blog/business-analyst-digital-agency), is whoever is responsible for doing the discovery work and turning it into scope.

Good scoping is only as accurate as the discovery underneath it. An agency can have an excellent scoping template and still produce bad estimates, if the inputs feeding that template were never confirmed in the first place.

## Where this gets harder as an agency grows

None of this is difficult to do once, for one project. It gets difficult to do consistently, across every active client, as an agency takes on more work at the same time. The senior person who used to sit in every discovery call cannot be in six calls at once, and the moment discovery quality depends on which project happens to get that person's attention, some projects will get quoted on guesses.

CommerceCopilot's Business Analyst agent is built around treating discovery as continuous rather than a one-time phase. It listens to the places requirements actually form, client calls, connected Slack channels, meeting transcripts, and maintains a living model of the project: the outcome, what is confirmed, what is assumed, and what is still an open question. When something is unclear, it raises the question instead of guessing, the same discipline [a well-run discovery process](/blog/shopify-agency-client-discovery-process) demands from a human team, applied to every active project rather than just the ones getting senior attention that week. The [discovery project guide](/docs/your-first-discovery-project) covers setting one up, including how accepted findings turn into sequenced, dev-ready tickets.

## FAQ

### What is the difference between discovery and requirements gathering?

They largely overlap. Requirements gathering usually refers to the act of collecting information from stakeholders; discovery is the broader process that includes gathering requirements, but also structuring, documenting, and validating them into something a developer can build from and a business can price against.

### How do I know when discovery is done enough to quote?

You do not need every question answered, only the ones that determine cost and architecture. A useful check: can you name the platform, the core pages or flows in scope, the integrations involved, and the client's definition of done? If yes, you have enough to price the project and sequence a first sprint, and the remaining open questions can be resolved as work begins rather than delaying the quote.

### Who should own discovery at a small agency?

Whoever is closest to both the client relationship and the technical constraints, which is often the founder or lead developer at a small shop. The risk is not that the wrong person does it; it is that discovery becomes whatever that person has time for that week, rather than a consistent step every project goes through before it gets priced.

---
Canonical page: https://www.commercecopilot.ai/fr/blog/what-is-shopify-project-discovery