WordPress Development
WooCommerce Build Scoping: What Agencies Miss in Client Quotes
WooCommerce builds overrun in predictable places: product data, tax, shipping, integrations and testing. Here is how to scope and structure the quote before you send it.
The quote said “WooCommerce store, 120 products, 3 weeks.” Eleven weeks later you are writing a VAT rule for digital goods sold to the EU, rebuilding the checkout because the payment provider needs a redirect, and importing a product feed whose variations do not match anything in WooCommerce. The build was not underestimated by a bit. It was scoped as though it were a brochure site with a basket.
WooCommerce projects blow up in predictable places. This post walks through where WooCommerce project scoping goes wrong, the questions that surface hidden work before you quote, and how to structure the number so change requests do not eat the margin.
WooCommerce is not a website with products bolted on
A marketing site has content, templates and forms. A store has inventory, tax, shipping logic, payment flows, order states, refunds, emails, customer accounts and at least one external system that must stay in sync. Every one of those is a place where the client’s business rules meet software that was designed for a general case.
That is why the scoping question is never “how many pages” — it is “how many rules”. Two stores with identical product counts can differ by a factor of five in build hours because one sells simple physical goods with flat shipping and the other sells configurable products with per-region tax treatment and a warehouse integration.
The eight areas agencies routinely under-scope
1. Product data model
Simple, variable, grouped, bundled, subscription and configurable products are entirely different build efforts. Ask for a real example of the most complicated product in the catalogue before quoting, not the simplest. A single product with three attributes and 40 combinations, each with its own stock level and image, is more work than 300 simple SKUs.
2. Catalogue migration
“We will send a CSV” hides a week. Real exports arrive with inconsistent attribute names, images referenced by filenames that do not exist, prices including tax in some rows and excluding it in others, and categories that only make sense to the client’s warehouse manager. Budget mapping and cleanup time, or state explicitly that the client supplies data in your template and owns its accuracy.
3. Tax
Domestic-only physical goods at a single rate is quick. Cross-border sales, digital goods, reverse charge for business customers, prices displayed inclusive in one market and exclusive in another — that is configuration, testing and often a dedicated tax service. Ask which countries they sell to on day one and which they plan to add.
4. Shipping rules
Flat rate is a checkbox. Weight bands per zone, free shipping above a threshold that excludes certain categories, oversized item surcharges, pickup points, or live carrier rates are all custom work. Shipping is where clients most often say “just like our old site did it” without knowing what the old site did.
5. Payments and checkout
Card payments through a mainstream gateway are routine. Local methods, bank redirects, buy-now-pay-later, invoicing for trade customers, saved cards, or a custom multi-step checkout each add integration and test cycles. Every payment method needs its own end-to-end test including a failed payment and a refund.
6. Integrations
ERP, accounting, fulfilment, PIM, CRM, email marketing, reviews. Each one needs field mapping, an agreed sync direction, error handling and a decision about what happens when the remote system is down. Ask for API documentation during scoping; if it does not exist, that is not a small detail, it is a project risk.
7. Emails and order lifecycle
WooCommerce ships a dozen transactional emails, all looking like default WooCommerce. Branding them, adding custom order statuses for the client’s actual process, and wiring notifications to the warehouse is real work that never appears in a proposal.
8. Performance at catalogue scale
Stores are dynamic, cart and checkout pages cannot be cached like a blog post, and faceted filtering on a large catalogue will hammer the database. Object caching, query tuning and hosting choice belong in the scope, not in a panicked call after launch. If you have already inherited a slow one, the process in our Core Web Vitals rescue walkthrough applies with the caveat that store pages need their own caching strategy.
A quick complexity model for WooCommerce project scoping
Before estimating hours, place the store in a tier. It gives you a shared vocabulary with the client and stops a tier-three build being quoted at tier-one prices.
| Tier | Characteristics | Scoping focus |
|---|---|---|
| Standard store | Simple products, one country, one gateway, flat or weight-based shipping, no integrations | Design build, catalogue import, testing |
| Configured store | Variable products, multi-country tax, two or three gateways, one marketing integration, branded emails | Rules documentation, test matrix, staging sign-off |
| Custom commerce | Subscriptions or bookings, B2B pricing tiers, ERP or fulfilment sync, custom checkout, large catalogue | Technical discovery as a paid phase; architecture before pricing |
The honest advice for tier three: do not give a fixed price from a sales call. Sell a short discovery phase, produce a technical specification and a test matrix, then quote the build. Clients who refuse to pay for discovery on a complex store are usually the same clients who will dispute every change request later.
Twelve questions to ask before you quote
- Show me your most complicated product and how it is priced.
- Which countries do you sell to now, and which within twelve months?
- Are your displayed prices tax inclusive or exclusive, and does that change by market?
- Exactly how is shipping calculated today, including every exception?
- Which payment methods are non-negotiable for your customers?
- What happens in your business between “order placed” and “order shipped”?
- Which other systems must know about an order, and do they have an API?
- Do you sell to businesses at different prices, or with credit accounts?
- Who supplies and owns the product data, and in what format?
- How many SKUs and variations, and how often do they change?
- Do you need subscriptions, bookings, deposits or partial payments?
- Who maintains this store after launch, and with what budget?
Questions six and twelve produce more scope surprises than any of the others. The order lifecycle exposes custom statuses and notifications nobody mentioned, and the maintenance question forces an early conversation about who patches a store that processes card payments.
How to structure the quote
Even a well-scoped store will change during the build, because the client learns what they actually want by seeing it. Structure the commercial terms so that is normal rather than a fight.
- Separate the phases. Discovery, design, build, data migration, integrations, testing, launch, hypercare. Priced separately, they can be re-quoted individually when something grows.
- Name the assumptions. One product type, one currency, two gateways, catalogue supplied in your template, up to N variations. Assumptions are what turn a scope dispute into a change order.
- Quote integrations with a range and a trigger. “Fixed price assumes documented REST API and a sandbox; without both, this moves to time and materials.”
- Budget testing explicitly. On a store, QA is not a rounding error. Every payment method, every shipping zone, every tax case, plus a refund and a failed payment.
- Include a launch window and a post-launch fortnight. The first real orders always find something.
On pricing your own margin, the mechanics are covered in how agencies price white label WordPress work. The point specific to commerce: your risk is concentrated in integrations and data, so those are the two line items that should never be fixed-price on faith.
Where outsourced capacity fits
Most agencies can build a standard store. The difficulty starts at tier two and three, where you need someone who has already dealt with tax edge cases, gateway quirks and sync failures. Hiring for that permanently is hard to justify unless commerce is your core offering.
The alternative is to keep strategy, design and the client relationship and buy the engineering. That is what white label WooCommerce development is for, and it is a normal part of the white label WordPress development model for agencies. Where the work is continuous rather than one-off, a monthly capacity arrangement usually prices better than per-project quotes: our dedicated monthly plans run from $699/mo for 15–20 hours up to $3,599/mo for 100–120 hours, month to month with no lock-in, which suits the stop-start rhythm of store work after launch.
The honest counter-case: if you build one small store a year, outsourcing adds coordination overhead you do not need, and a good freelancer on a per-project basis is cheaper and simpler. Capacity arrangements earn their keep when the work is regular.
Frequently asked questions
Should I ever fix-price a WooCommerce build?
Yes, for standard stores with documented rules and no integrations. Beyond that, fix-price the phases you control and use time and materials or a re-quote trigger for data migration and third-party integrations.
How much should we budget for testing?
Enough to run every combination of payment method, shipping zone and tax case at least once, plus refunds and failures. Build the test matrix during scoping — it doubles as evidence of what was in scope.
Is WooCommerce the right platform for a large catalogue?
It handles large catalogues with proper hosting, object caching and query discipline, and it gives you full ownership of the code. If the client wants zero infrastructure responsibility and a rigid feature set, a hosted platform may genuinely serve them better. Say so rather than forcing the fit.
What is the most common cause of overrun?
Product data. The catalogue arrives late, in the wrong shape, and changes during the build. Fixing the format and the deadline for delivery in the contract removes more risk than any technical decision.
Do stores need a maintenance retainer?
More than any other WordPress site. A store handles payment flows and customer data, and an unpatched plugin has commercial consequences, not just cosmetic ones. Quote the retainer alongside the build, not after it.
If you have a store to quote and want a sanity check on the hours before it goes to the client, send the requirements over and we will tell you which parts we would price differently and why.
// related