Shopify Scope Variables: The 15 Inputs That Determine 90% of Your Scope

If you've ever written two Shopify scopes for seemingly similar projects and ended up with wildly different documents, you've already discovered scope variables — you just didn't have a name for them.

Scope variables are the inputs that determine the shape of a scope document. They're the answers to questions like: is this a migration or a new build? How many markets? Is B2B involved? Are there ERP integrations?

Change one variable and the scope changes with it. A single-market DTC store with 100 products is a fundamentally different scope from a multi-market B2B/DTC hybrid with ERP integration — even if the client describes both as "a Shopify store."

The problem isn't that agencies don't know this. The problem is that most agencies handle these variables implicitly. A senior person holds the mental model of "if X, then the scope needs Y" — and when that person is unavailable, on holiday, or leaves the company, the scoping quality drops.

This page makes those variables explicit. It's a reference for the inputs that drive the vast majority of decisions in a Shopify scope of work — what sections to include, what deliverables to list, what to exclude, and where the hours go.

If you're building a repeatable scoping process, this is where you start.

---

Each variable below controls multiple decisions in your scope document. For each one, we explain what it determines, the common values it takes, and what changes in the scope when the value changes.

What it determines: Baseline deliverables, effort assumptions, project phases

Common values:

• New build — Starting from scratch. Full design, full development, full content.
• Redesign — Existing Shopify store, new theme/UX. Partial content migration, existing data stays.
• Migration — Moving from another platform (WooCommerce, Magento, BigCommerce, custom). Adds data migration, SEO redirect mapping, and platform-specific considerations.
• Feature addition — Specific functionality added to an existing store. Narrowest scope.

What changes: Migrations add an entire workstream that new builds don't have: data mapping, redirect plans, SEO preservation, parallel running periods, and go-live cutover planning. A migration scope that's priced like a new build will lose money. A new build priced like a migration will lose the deal.

What it determines: Data migration effort, template logic, testing scope, collection architecture

Common values:

• Small — Under 100 SKUs, simple variants (size/colour)
• Medium — 100–2,000 SKUs, moderate variant complexity
• Large — 2,000–10,000+ SKUs, complex variants, bundles, or configurable products

What changes: A small catalogue might need one product template. A large catalogue might need 3–4 product templates (simple product, bundle, configurable, digital). Large catalogues also need import/export tooling, automated collection rules, and more extensive QA — you can't manually check 5,000 products.

Gotcha to flag: Shopify's 100-variant limit per product and 3-option limit catches clients migrating from platforms without these constraints. If the client has products with 150+ variants, you need a restructuring plan in the scope.

What it determines: Design and development hours — directly

Common values:

• Standard (4–6): Homepage, collection, product, page, blog, cart
• Extended (7–12): Above + landing pages, lookbook, about, FAQ, comparison pages
• Custom-heavy (12+): Highly editorial or campaign-driven sites

What changes: Every unique template is a design deliverable (wireframe → mockup → revisions) and a development deliverable (Liquid template, section schema, mobile responsiveness). Going from 6 to 12 templates can double the design and front-end budget.

What it determines: Multi-market configuration, content translation effort, tax/duties setup, theme adaptation

Common values:

• Single market — One country, one language, one currency
• Multi-currency — One language, multiple currencies (simplest multi-market)
• Multi-language — Multiple languages, with or without market-specific pricing
• Full multi-market — Different products, pricing, content, and compliance per region

What changes: Single market? No Shopify Markets configuration needed. Multi-language? Translation effort, app setup (Translate & Adapt or Weglot), and theme translation keys. Full multi-market? You might need separate Shopify Markets configurations or even separate stores — plus market-specific compliance (VAT, cookie consent, accessibility standards).

Scope impact: Each additional market can add 15–30% to the base scope, depending on depth of localisation.

What it determines: Whether B2B features (Shopify Plus native B2B, or third-party apps) are in scope

Common values:

• No B2B — DTC only
• Light B2B — Discount codes or wholesale pricing via tags/apps
• Native B2B (Shopify Plus) — Company accounts, custom catalogues, payment terms, quantity rules
• Separate B2B store — Dedicated wholesale storefront (Shopify expansion store or separate instance)

What changes: No B2B keeps the scope clean. Native B2B on Plus adds company setup, catalogue configuration, payment terms, and a second set of UX testing for the B2B buyer experience. A separate B2B store is effectively a second project.

What it determines: POS hardware, staff accounts, inventory sync, omnichannel configuration

Common values:

• No POS — Online only
• Shopify POS (1–3 locations) — Standard setup
• Shopify POS (4+ locations) — Multi-location inventory, staff permissions, hardware rollout plan

What changes: POS adds hardware procurement, location-based inventory configuration, staff training, and potentially custom receipt templates. Multi-location POS also raises inventory management complexity (transfer workflows, location-specific stock levels).

What it determines: The number and difficulty of third-party system connections

Common values:

• Low — Email marketing + reviews (Klaviyo + Judge.me). Standard apps, standard setup.
• Medium — Above + 1–2 operational integrations (shipping, helpdesk, loyalty)
• High — ERP, WMS, 3PL, custom middleware, or legacy system connections
• Very high — Multiple ERPs, custom APIs, real-time inventory sync across channels

What changes: Low integration complexity is standard Shopify app installation and configuration. High complexity introduces API mapping, staging/sandbox environments, error handling, retry logic, and integration-specific QA. Very high complexity often requires a dedicated integration workstream with its own timeline.

Rule of thumb: Each "high complexity" integration adds 20–60 hours to the scope, depending on API quality and documentation.

What it determines: Third-party dependencies, compatibility testing, and potential conflicts

Common values:

• Flexible — No strong app preferences, open to recommendations
• Partially locked — Specific apps required (e.g., "we must use Recharge for subscriptions")
• Fully prescribed — Client dictates the full app stack, potentially including apps with known compatibility issues

What changes: A flexible app stack lets you recommend tested combinations. A prescribed stack means you need to validate compatibility upfront and may need to work around app limitations. If the client insists on an app that conflicts with the theme or another app, that's debugging time you need to scope.

What it determines: Tracking setup, data layer configuration, consent management

Common values:

• Standard — GA4 + one ad pixel
• Enhanced — GA4 + multiple ad pixels + GTM + custom events
• Advanced — Server-side tracking, custom data layer, attribution modelling

What changes: Standard is 2–4 hours. Enhanced is 8–16 hours. Advanced is 20+ hours and may require a specialist. Server-side tracking (via GTM server container or Shopify's Customer Events API) is increasingly requested but adds significant setup and testing.

What it determines: Whether content creation is in scope and how it affects the timeline

Common values:

• Ready — All content (copy, images, video) provided by client before development starts
• Partially ready — Some content exists, some needs creation
• Not ready — Content needs to be created as part of the project

What changes: Content readiness is the #1 predictor of whether a project ships on time. If content isn't ready, you either scope content creation (which adds cost) or build a content-dependent timeline with explicit client delivery dates (which adds risk). Either way, the scope document needs to address it.

What it determines: Whether design is in scope, and the depth of design work

Common values:

• Client-provided design — Figma/Sketch files delivered, agency implements
• Theme customisation — Start from a premium theme, customise to match brand
• Custom design — Full UX/UI design from wireframes through to high-fidelity mockups
• Design system — Custom design with component library and documentation

What changes: Client-provided design is development-only scope. Theme customisation adds configuration and minor CSS/Liquid work. Custom design adds a full design phase (discovery → wireframes → mockups → revisions) that typically takes 3–6 weeks and requires its own deliverables and approval milestones.

What it determines: Phasing, resourcing, parallel workstreams, risk buffer

Common values:

• Flexible — No hard deadline, quality over speed
• Target date — Preferred launch date, some flexibility
• Hard deadline — Non-negotiable (e.g., Black Friday, product launch, platform contract expiry)

What changes: A hard deadline may force you to run workstreams in parallel (design and development overlapping, rather than sequential), bring in additional resources, or descope features to phase 2. The scope document should explicitly state what's included in phase 1 vs. phase 2 when a hard deadline drives phasing decisions.

What it determines: Whether ongoing work is included, and the handoff expectations

Common values:

• Clean handoff — Project ends at launch, no ongoing support
• Warranty period — 30–90 days of bug fixes included post-launch
• Retainer — Ongoing monthly support hours for maintenance and improvements
• Managed service — Agency continues to operate/optimise the store

What changes: Clean handoff means your scope ends at launch (plus documentation and training). A warranty period needs to be explicitly defined — what's a bug vs. a change request? A retainer adds a separate commercial agreement. Each option changes the scope document's "post-launch" section and the commercial terms.

What it determines: Data migration effort, SEO preservation, cutover plan

Common values:

• Simple — Small catalogue, few redirects, no complex data
• Standard — Medium catalogue, URL redirect mapping, customer data migration
• Complex — Large catalogue, complex data structures, gift cards, subscriptions, extensive SEO work, parallel running period

What changes: Simple migration might use Shopify's built-in import tools. Complex migration needs Matrixify or custom scripts, a full redirect map (potentially thousands of URLs), customer notification plan, and a defined cutover procedure with rollback plan.

What it determines: Legal and accessibility requirements that add development and testing scope

Common values:

• Standard — Basic privacy policy, terms of service
• GDPR/CCPA — Cookie consent management, data handling procedures, privacy-by-design considerations
• WCAG AA — Accessibility compliance adding design constraints, development standards, and audit requirements

What changes: GDPR/CCPA adds consent management (Pandectes, OneTrust, etc.), cookie categorisation, and potentially data processing documentation. WCAG AA adds accessibility testing, remediation, and potentially an external audit — 20–40+ hours depending on template count and complexity.

---

Every agency that's tried to standardise scoping has built some version of this checklist — in a spreadsheet, a Notion database, or the head of their most experienced project manager.

The limitation is always the same: the variables are captured, but the scope document is still assembled manually. Someone reads the variables, opens a template, and decides what to include. That manual assembly step is where inconsistency creeps in — and where senior people's time gets consumed by work that should be systematic.

RuleDox makes the variables operational. Each variable on this page connects to rules in RuleDox. When you set the variable values for a project, rules determine:

• Which sections appear in the scope document (e.g., B2B sections only appear when B2B = yes)
• Which deliverables are included (e.g., redirect mapping only appears for migrations)
• Which exclusions are listed (e.g., content creation excluded when Content Readiness = Ready)
• How hours and effort are calculated (e.g., integration hours scale with complexity level)

The output is a structured Google Doc — your scope document, assembled from your rules, consistent across your team.

The checklist on this page gives you the framework. RuleDox gives you the engine.

Need a structured way to collect these variables from clients? See the Intake Questionnaire →

Try the live demo → — Set some variables, see the rules in action, get a real scope document in Google Docs.