Scoping an eCommerce Build: What a Discovery Should Cover Before Anyone Quotes You

A fixed price quoted before discovery is a placeholder with a decimal point. It is not dishonest; it is arithmetic performed on assumptions, and the assumptions are the part that will change. Three things determine what an eCommerce build actually costs: the data model, the integration surface, and the commercial rules the system has to express. A discovery that has not put those three on the table has not produced a number anyone should sign.

This is the checklist a serious discovery works through, with what specifically changes in a quote when each item is skipped. Use it to prepare for your own discovery, or to judge whether the one you were given did its job.

Why quotes move, and in which direction

Quotes almost never move down after discovery. They move up, and they move up for a small set of recurring reasons.

Someone discovers that pricing is not one price list but a rule set with exceptions. Someone discovers that the ERP does not expose the field the build assumed it would. Someone discovers that three thousand products carry attributes that exist only in the description text. None of those are unusual, and all of them are findable before a number is written.

The point of a discovery is not to eliminate uncertainty. It is to move uncertainty from the invoice into the scope document, where it can be discussed while both sides still have options.

Checklist one: the commercial model and pricing rules

The most underestimated section, and the most likely to change a quote materially.

• Every price a product can have, and what determines which one applies: list price, contract price per account, volume tiers, promotional price, currency and market variations.
• Who is entitled to see what. Whether all customers see the full catalog, or whether entitlement varies by account, market, or channel.
• Payment terms and methods by customer type, including invoice terms if any customer buys that way.
• Tax treatment across the markets in scope, including whether prices display inclusive or exclusive by market.
• Promotions and their interaction rules. What stacks with what, and what is forbidden. This list is longer than most teams expect and is rarely written down anywhere.
• Order minimums, increments, and any rules about who can order how much.

What changes when this is skipped: pricing logic gets discovered during build, usually as a request that arrives after the data model is fixed. That is the single most common cause of a mid-project scope conversation, because pricing rules touch the catalog, the cart, the checkout, and the reporting at once.

Checklist two: the data model and catalog

• Product count, variant count, and the true option structure. A thousand products with four options each behaves differently from four thousand simple products.
• Where every attribute currently lives. Structured fields, custom fields, or prose in the description. The third category is a migration project rather than a mapping exercise.
• Configured, bundled, or kitted products, and how their price and availability are derived.
• Which system is the source of truth for each field. Commerce platform, ERP, PIM, or a spreadsheet somebody maintains. Naming the spreadsheet is not embarrassing; discovering it in month three is expensive.
• Customer and account structure. Whether customers are individuals, companies with locations and users, or both.
• Media: how many images per product, who produces them, and whether they exist for the full catalog or only the products currently promoted.

What changes when this is skipped: the build assumes clean structured data and receives prose. Attribute extraction is slow, manual, and lands on a merchandising team who did not know it was coming.

Checklist three: the integration surface

• Every system the store must exchange data with, named, with a version and an owner. ERP, PIM, WMS, POS, CRM, marketing automation, accounting, shipping and returns.
• For each: direction, frequency, and volume. One-way nightly is a different build from bidirectional near-real-time, and the difference is not marginal.
• API reality, not API existence. Whether documentation exists, whether the endpoints expose the fields required, what the rate limits are, and who at the vendor can answer a question.
• What happens when a sync fails. Retry behaviour, alerting, and who is notified. Absence of an answer here is a finding.
• Middleware: whether one exists, whether it is being kept, and who maintains it.
• Authentication and access, including who can grant credentials for each system and how long that usually takes.

What changes when this is skipped: integration is quoted as a line item and delivered as a project. The recurring pattern is that an ERP’s documented API turns out not to expose one field the commercial model depends on, and the workaround is neither small nor obvious.

Checklist four: existing assets and migration

• A full crawl of the current site, producing a complete URL inventory rather than a sitemap. The two differ, usually substantially.
• Redirect mapping approach, agreed as one-to-one wherever an equivalent page exists.
• Content inventory: what moves, what gets rewritten, and who writes it. Content is the most frequently unassigned workstream in a build.
• Historical data: how much order history migrates, and whether customer accounts and passwords carry across.
• Existing customisations, sorted into what encodes business logic and what works around the platform being left. The second group should not be rebuilt, and saying so early is worth more than saying it later.
• SEO baseline: current rankings, traffic, and top-performing pages recorded before anything changes, so post-launch movement is measurable.

What changes when this is skipped: the redirect map gets built from a sitemap that omits a third of the indexed pages, and traffic decline after launch is discovered too late to diagnose. Migration path choices are covered in more depth in our piece on replatforming without breaking the business.

Checklist five: ownership and decision rights

The section that looks like project administration and behaves like a technical dependency.

• Who signs off, per area. Design, commercial rules, data, integrations. One name each.
• How long a decision takes in your organisation, honestly. A two-week approval cycle on a twelve-week build is a scheduling fact, not a detail.
• Who owns product data and has capacity to work on it during the project.
• What internal resource is committed, in hours rather than in intent.
• Which stakeholder has not been in the room yet. Finance and customer service are the usual answers, and both surface requirements late when they are excluded early.

What changes when this is skipped: the timeline holds until it meets your approval process, then absorbs the difference. This is the most common cause of a delay that neither party can attribute to the other.

Signals that a discovery was real

Approach any discovery, including ours, with these tests.

They asked to see your systems, not just hear about them. 

A discovery conducted entirely in meetings has taken your description of your data at face value. Reading the actual catalog export and the actual API documentation is what surfaces the surprises.

They asked uncomfortable questions about ownership. 

Who decides, who has capacity, which stakeholder has not been consulted. An agency that avoids these is protecting the sales process rather than the project.

They told you something you did not want to hear. 

A discovery that concludes everything is straightforward and the original budget is exactly right has either found a genuinely simple project or has not looked hard.

They separated what they know from what they assume. 

A scope document that marks its assumptions explicitly is more valuable than one that reads as certainty, because the assumptions are what you will negotiate against later.

They produced artifacts, not a proposal. 

A discovery output should include a data model, an integration map, a decision log, and a risk register with owners. A slide deck with a price on the last page is a proposal that used the word discovery.

They were willing to recommend against the build. 

Sometimes the honest finding is that remediation on the current platform is smaller and cheaper, or that the constraint is organisational rather than technical. That conversation is covered in our piece on the eCommerce scaling decisions brands reach too late.

What you should hold at the end

Six artifacts, and you should be able to hand them to a different agency and have them understand the project.

1. A data model covering products, variants, attributes, customers, accounts, and where each field originates.
2. An integration map naming each system, direction, frequency, and owner.
3. A documented commercial rule set: prices, entitlement, promotions, terms, and their interactions.
4. A scope statement separating what is included, what is explicitly excluded, and what is assumed.
5. A risk register with named owners and mitigations, not a generic list.
6. A migration and search continuity plan, including the URL inventory and redirect approach.

Portability is the test that matters. A discovery whose output only makes sense to the agency that produced it has not reduced your risk; it has concentrated it.

Before you commit to a build quote

If you are collecting quotes for a build or a replatform, the useful sequence is discovery first, then pricing, with the discovery scoped and paid for on its own terms so the output belongs to you regardless of who builds it.

Flatline’s eCommerce discovery maps the data model, the integration surface, and the pricing rules before scope is fixed, and produces the six artifacts above as portable documents. We are a Shopify Platinum Partner, and the discovery is designed to be useful even if the build goes elsewhere. Book a scoped discovery before committing to a build quote.

Frequently Asked Questions

How long should an eCommerce discovery take? 

For a mid-market build, two to four weeks of elapsed time with a few days of concentrated work from your team. Less than that generally means the systems were described rather than examined. Considerably more usually means the scope of the build itself is unsettled, which is a different conversation.

Should we pay for a discovery? 

A paid discovery produces documents that belong to you and can be given to any agency, including one you do not end up hiring. A free discovery is a sales activity, which does not make it worthless but does mean its depth is bounded by the cost of producing it. If you pay, confirm in writing that the output is yours.

What if an agency quotes without a discovery? 

Ask what assumptions the number rests on and what would change it. A good answer lists specific assumptions about data, integrations, and pricing rules. A vague answer means the number will move once those things are examined, and it will move upward.

Can we run the discovery ourselves? 

Partly, and it is worth doing. The catalog audit, the system inventory, and the written pricing rules are all work your team can complete before engaging anyone, and doing so shortens every discovery that follows. What is harder to self-assess is integration feasibility, since that requires knowing what the target platform can and cannot express.

Key Takeaways

• Quotes move upward after discovery, for a small set of recurring reasons: undiscovered pricing rules, integration fields that do not exist, and attributes living in prose rather than structured fields.
• Three areas determine cost more than any other: the commercial rule set, the data model, and the integration surface. A quote produced without all three is arithmetic on assumptions.
• Ownership and decision rights belong in the discovery. Approval cycles and unassigned data work are the most common causes of delay that neither party can attribute to the other.
• Judge a discovery by its artifacts and its portability. A data model, integration map, rule set, scope statement, risk register, and migration plan that another agency could pick up is what reduces your risk.

The discovery is the cheapest part of a build and the part with the most leverage over everything after it. A few weeks spent establishing what is actually true about your data, your systems, and your commercial rules is the difference between a quote you can hold someone to and a number that starts moving in month two.