How to Compare Shopify Theme Proposals Beyond Headline Price

A Shopify theme proposal can look precise while leaving the most important delivery questions unanswered.

It may contain a timeline, a price and a list of pages. It may describe a premium experience, flexible components and best-practice development. But those phrases do not reveal which problems will be investigated, which templates and states will be delivered, how apps will be integrated, what will be tested or what the merchant will own.

That is why three proposals for the “same” project can have very different prices without describing equivalent work.

The objective is not to make every proposal identical. It is to normalize them sufficiently that the differences become intentional, understandable and priced.

Headline price is the result of hidden decisions

A proposal price reflects more than design and development time. It also reflects how scope, uncertainty and delivery risk have been allocated.

One agency might include research, content modelling, edge cases, migration and post-launch stabilization. Another might exclude them. One may assume the client will provide complete approved content. Another may include content support. One may price custom components. Another may configure an existing theme.

Before comparing totals, identify:

• What outcome each proposal believes it is delivering.
• What work is included, optional or excluded.
• Which assumptions make the price possible.
• Which responsibilities remain with your team.
• Which uncertainties may become change requests.
• Which risks are being resolved, accepted or transferred.

The cheapest proposal can become expensive when missing work is discovered during delivery. The highest proposal can also be poor value if its additional cost does not address relevant outcomes or risks.

First, create one comparison baseline

Do not use each proposal’s structure as the comparison structure. Create your own baseline from the approved project brief.

The baseline should state:

• Business and customer problems.
• Required journeys, functionality and merchant workflows.
• Template and content requirements.
• Existing theme, apps, integrations and data.
• Markets, languages and currencies in scope.
• Accessibility, performance, SEO and analytics expectations.
• Content, migration, training and launch responsibilities.
• Timeline constraints and important trading dates.
• Required ownership, documentation and support.

Then classify every baseline item in each proposal as:

• Included — explicitly part of the fixed scope.
• Optional — available with a separate price or decision.
• Assumed — priced on a condition that must be confirmed.
• Excluded — deliberately outside the proposal.
• Unclear — not addressed or too ambiguous to rely on.

Compare discovery—not only deliverables

Discovery determines whether the team is solving the right problem before expensive implementation begins.

Compare:

• Stakeholder, customer and operational inputs.
• Analytics, search, support and performance evidence.
• Current-theme, app and integration audit.
• Catalogue, content and navigation review.
• Technical feasibility and dependency investigation.
• Prioritization and acceptance criteria.
• Expected outputs and approval points.

A workshop is not automatically useful discovery. Ask what evidence will be collected, what decisions it will support and what artefacts will be produced.

If discovery is excluded because the brief is already detailed, confirm how the agency will validate assumptions. If it is extensive, confirm why that depth is proportionate to the project.

Compare template and state coverage

“Homepage, product page and collection page” rarely describes the complete storefront.

Shopify’s theme architecture uses layouts, templates, section groups, sections, blocks and supporting assets. Proposals should therefore identify not only visible page concepts, but the reusable system and variations behind them.

Create a coverage matrix containing:

• Homepage and campaign landing pages.
• Collection, search and filtering states.
• Product templates and product-type variations.
• Cart, drawers and purchase feedback.
• Standard pages, editorial content and policy templates.
• Header, footer, navigation and announcement systems.
• Account or other Shopify surfaces where relevant.
• Empty, loading, unavailable, error and long-content states.
• Mobile, desktop and important responsive behaviour.
• Market, language, currency and content variations.

For each item, ask whether the proposal includes discovery, design, implementation, content setup and testing. A designed page is not necessarily a built template, and a built template is not necessarily populated or tested.

Also compare merchant control. Which sections and blocks can editors use? Where can they be reordered? Which settings and safeguards are included? How will the agency prevent flexibility from becoming an inconsistent or overwhelming editor?

Compare the technical approach

Two storefronts can look similar while creating very different ownership costs.

Ask each team to explain:

• Whether it will configure an existing theme, customize a theme or create a new implementation.
• Which capabilities remain native and which require code, apps or external services.
• How reusable sections, blocks, snippets and structured data will be organized.
• Where business logic and data will live.
• How source control, environments, reviews and releases will work.
• How the approach supports future theme and platform updates.
• How performance, accessibility and failure behaviour influence implementation.

Avoid rewarding complexity for its own sake. A simpler approach can be stronger when it meets the requirement cleanly. Equally, a low-code proposal is not automatically maintainable if it creates duplicated templates, excessive settings or operational workarounds.

Shopify advises merchants to treat theme code edits carefully because incompatible changes might not transfer to updated theme versions. Proposals involving substantial code modification should explain version control, update strategy, documentation and regression testing.

Make app dependencies visible

An app can be a responsible way to adopt mature functionality. It can also change recurring cost, performance, data flows, support and exit options.

For every required or recommended app, record:

• Purpose and requirement served.
• Existing, replacement or newly introduced dependency.
• Subscription, usage and transaction costs.
• Data access, storage and ownership.
• Storefront scripts, blocks or embeds.
• Theme integration and styling work.
• Migration or configuration responsibility.
• Vendor support and business-continuity considerations.
• Removal, replacement and cleanup requirements.

Do not compare a proposal using existing paid apps with one including app replacement as if the technical and recurring costs are equivalent.

Where an app integrates through Shopify’s theme app extension model, app blocks and embeds can be managed without directly editing theme code. That is useful architectural information, but the proposal must still include configuration, styling and testing where required.

Compare QA as defined work

“Fully tested” is not a test plan.

A credible proposal should identify:

• Test responsibility and environments.
• Browsers, devices, screen sizes and input methods.
• Journeys, templates, integrations and operational workflows.
• Content, product and customer states.
• Test orders and relevant payment, shipping and notification flows.
• Analytics, consent, SEO and redirect validation.
• Defect severity, reporting, acceptance and retesting.
• Pre-launch, launch-day and post-launch checks.

Clarify who supplies devices, test data, accounts and app credentials. Ask which defects block launch, what warranty or stabilization period applies and how unresolved issues are handled.

QA effort should match risk. A focused theme adjustment and a multi-market rebuild should not carry identical test scopes.

Treat accessibility and performance as scope

Accessibility and performance should appear as activities, standards and evidence—not adjectives.

For accessibility, compare:

• Design requirements for contrast, focus, semantics and interaction.
• Keyboard, zoom, error and assistive-technology testing.
• Automated and manual checks.
• Responsibility for app and content-related issues.
• Remediation and acceptance process.

Shopify’s accessibility guidance notes that following documented best practices alone does not guarantee a completely accessible theme. A proposal should explain the testing it will actually perform.

For performance, compare:

• The baseline, pages and metrics used.
• Lab and field measurement where available.
• Image, font, Liquid, JavaScript and third-party-script practices.
• Performance budgets or agreed guardrails.
• How regressions will be detected before and after launch.

Shopify publishes detailed theme-performance practices, but a proposal must convert principles into work appropriate to the store.

Compare documentation, ownership and support

Confirm the proposal’s position on:

• Theme and application source code.
• Git repositories and commit history.
• Design source files and component documentation.
• Theme licenses, app accounts and infrastructure accounts.
• Credentials, domains and third-party services.
• Data exports and migration assets.
• Merchant guidance and team training.
• Technical handover and known limitations.
• Warranty, support scope, response expectations and ongoing rates.

Ownership should mean practical control, not merely a sentence saying the client owns the work. Your team should know where the assets live, who can access them, how the system is released and what knowledge is required to change it.

Read assumptions and exclusions as commercial terms

Assumptions explain conditions used to calculate the price. Exclusions identify work the supplier is not committing to deliver.

Common examples include:

• Content will be final before implementation.
• Existing apps will remain compatible.
• Product data requires no restructuring.
• The client will manage migration or translations.
• Only named templates and review rounds are included.
• Third-party defects are excluded.
• Accessibility applies only to custom components.
• Post-launch support is separately billed.

Do not treat these statements as administrative detail. Convert each one into an owner, action, date, cost or accepted risk.

Also examine change control. What qualifies as a change? How is impact assessed? Who approves cost or timeline changes? How are discoveries handled when neither party could reasonably confirm them before work began?

A proposal with more explicit assumptions may be safer than one that appears comprehensive because it says very little.

Calculate total cost of ownership

Compare more than the project fee.

Include:

• Discovery, design, development and project management.
• Theme licenses and initial app setup.
• Content production, data preparation and migration.
• Internal staff time and specialist dependencies.
• App subscriptions, usage charges and infrastructure.
• Testing, launch and stabilization.
• Training and documentation.
• Maintenance, updates and support.
• Future switching, cleanup or replacement effort.
• The likely cost of unresolved risks and exclusions.

Use the same time horizon and assumptions for every proposal. Record uncertain costs as ranges or scenarios instead of hiding them.

Total cost of ownership does not make the highest proposal the best. It helps determine whether a higher initial price removes relevant recurring cost or risk—and whether a lower price remains lower after the missing work is included.

Minimum-deliverables checklist

Adapt this checklist to the project, then ask every supplier to confirm each line.

Direction and scope

• Defined business, customer and operational outcomes.
• Discovery method, evidence and outputs.
• Approved requirements, priorities and acceptance criteria.
• Template, component, state and responsive coverage.
• Assumptions, exclusions, dependencies and optional work.

Design and content

• Customer journeys and realistic content states.
• Reusable design system and component behaviour.
• Merchant editing experience and content model.
• Accessibility requirements in design.
• Content, localization and migration responsibilities.

Technical delivery

• Theme foundation and customization approach.
• Native, app, custom and integration boundaries.
• Source control, environments, review and release process.
• Performance approach and agreed evidence.
• App inventory, recurring costs and data dependencies.

Quality and launch

• Test matrix, environments and responsibilities.
• Accessibility testing method and remediation.
• Analytics, SEO, redirect and consent validation.
• Launch sequence, acceptance, monitoring and rollback.
• Stabilization period and defect-handling terms.

Ownership and support

• Ownership of code, designs, accounts, data and credentials.
• Documentation, training and technical handover.
• Warranty, ongoing support and escalation route.
• Maintenance responsibilities and rates.
• Change-control and termination arrangements.

Proposal-comparison checklist

For each proposal:

1. Map every baseline requirement to included, optional, assumed, excluded or unclear.
2. Normalize template, state and responsive coverage.
3. Record the technical method and resulting ownership model.
4. Add apps, internal work, migration, support and recurring costs.
5. Identify evidence behind QA, accessibility and performance claims.
6. Convert assumptions and exclusions into costs, owners or risks.
7. Check ownership, handover, warranty and post-launch support.
8. Compare the same total-cost period and scenarios.
9. Ask suppliers to resolve material unknowns in writing.
10. Choose based on outcome fit, evidence, ownership and risk—not price alone.

Compare what the business will actually receive

The goal of proposal review is not to make the lowest price look suspicious or the highest price look sophisticated.

It is to understand the complete exchange: what the supplier will discover, design, build, test, document and support—and what the client must provide, own or accept.

Once scope and lifecycle costs are normalized, price becomes more useful. It can be discussed alongside delivery evidence, working fit and the risks each proposal genuinely resolves.

Digiff helps ecommerce teams define and deliver Shopify theme projects with clear scope, technical boundaries, quality practices and long-term ownership.

If your team is comparing Shopify proposals, begin by turning each one into the same coverage, cost and risk model before selecting a partner.