Not page count. The three things that move a Shopify quote most are the state of your product data, the number of systems the store has to talk to, and how much of the content doesn’t exist yet. Design and front-end build are the visible part of the estimate and rarely the volatile part.
If a quote surprises you, one of those three is usually the reason.
Driver 1: the condition of your product data
This is the most underestimated line in almost every project.
A catalogue where products have consistent options, complete attributes, and a sane category structure can be migrated and merchandised quickly. A catalogue where colour lives in the title for some products and in a tag for others, where variants were created inconsistently, and where nobody can say which of forty tags are still in use, cannot.
The work isn’t technical difficulty. It’s decisions — hundreds of small ones that only someone who knows the business can make, which means it can’t be delegated to the build team and can’t be parallelised.
What raises this cost:
- Product attributes stored in tags rather than metafields
- Inconsistent variant structures across similar products
- No product category assigned, so no standard attributes
- Data spread across a spreadsheet, an old platform, and someone’s head
The way to reduce it is to do the audit before the project rather than during it. It’s the same work either way. Doing it first makes it cheaper and removes it from the critical path.
Driver 2: integrations
Each system the store connects to — ERP, PIM, warehouse, accounting, CRM, subscriptions — adds cost that scales with how bidirectional it is.
Reading data out is cheap. Writing data back is moderate. Keeping two systems in sync, with conflict handling for when they disagree, is expensive and is where projects overrun.
The question to ask about each integration: what happens when the two systems disagree? If nobody has an answer, that’s unscoped work sitting in the estimate.
An off-the-shelf connector, where one exists and fits, is an order of magnitude cheaper than a custom integration. Check for one before assuming custom.
Driver 3: content
Design work is quoted against a page count. Content is what actually determines whether those pages ship.
Photography that doesn’t exist, product descriptions in inconsistent voice and length, no category copy, no size guides, no policy pages that survived the last site — this is the single most common cause of a launch date moving. And a delayed launch costs the same as extra scope, because the team is still allocated.
If the store is multilingual, multiply. Translation is per-locale content work, not a switch.
Driver 4: plan-gated requirements
Some requirements aren’t priced in development hours at all. They’re priced in a subscription.
Custom checkout UI extensions, the checkout editor for core checkout steps, the Checkout Branding API, and B2B checkout customisation all require Shopify Plus. Building custom Functions to replace bespoke logic is also Plus. If any of those appear in the brief, the cost is a plan upgrade, and Plus starts around $2,500 a month.
This is worth establishing in the first conversation, because it can change the entire shape of a project. A requirement that reads like two weeks of development sometimes turns out to be a $30,000 annual line item instead.
Driver 5: who maintains it afterwards
A build designed for a team that will edit it needs custom sections with well-designed schema settings, sensible defaults, and constraints that prevent the layout being broken. That’s real work, and it’s usually cut first when a budget tightens.
Cutting it moves the cost rather than removing it. Every campaign then needs a developer. Over two years, that costs more than the section work would have, and it’s charged at agency day rates rather than being in the build.
What’s cheaper than people expect
- Custom sections. Once the pattern is established, additional sections are incremental.
- Design distinctiveness. Making a store look unmistakably like the brand is design work inside a theme, not architecture. It’s one of the cheapest high-impact things in a project.
- Filtering. Native filtering is configured, not built, on any current theme.
- Speed. Most performance gain comes from removing app scripts and fixing images, not from a rebuild.
What’s more expensive than people expect
- Data migration, for the reasons above
- Bidirectional integrations
- Content and photography
- Multi-currency and multi-locale, which touch pricing, tax, shipping, translation, and filtering all at once
- B2B, which is closer to a second store than a feature
- The last 5% — QA across devices, edge cases, redirects, accessibility fixes. Consistently underestimated, consistently non-optional
Reducing cost without reducing outcome
Clean the product data before the project starts. Biggest single lever.
Cut locales, not features. Launching in one language and adding the second later is far cheaper than launching in two.
Establish plan requirements first. Find out whether anything in the brief requires Plus before the brief is finalised.
Reduce page types, not pages. Twenty pages using four templates is much cheaper than eight pages using seven.
Don’t cut the maintainability work. It’s the cut that costs the most later.
The question worth asking a quote
Not “why is it this much” but “which parts of this are uncertain, and what would resolve them?”
A well-constructed estimate has a firm part and a contingent part, and the contingent part is almost always data, integrations, or content. If a quote doesn’t distinguish between the two, that’s the thing to raise — an estimate presented as a single confident number is usually either padded or about to be revised.