Most stores hire a WooCommerce agency twice. The second time is the expensive one, because it includes undoing the first.
The pattern is consistent. A founder picks on price and portfolio screenshots, gets a store that looks right, and discovers eighteen months later that it cannot be extended without breaking, that nobody documented anything, and that the plugin stack has quietly become a liability. The rebuild costs more than the original because it also has to preserve the rankings and the customer data the first build accumulated.
This guide is about avoiding that. It is written by a team that does this work, so read it with that in mind — but the questions below are the ones we would want a client to ask us, and the warning signs are ones we have been hired to fix.
What a WooCommerce agency should actually be able to do
The label covers a wide range of capability, from theme installers to teams that build custom platforms. Three tiers, plainly:
| Tier | What they do | Right for |
|---|---|---|
| Theme configuration | Install a commercial theme, configure plugins, style it | A first store under ~200 SKUs with standard needs |
| Custom theme development | Build a bespoke theme on a modern stack, custom post types, ACF | Stores with a real brand, catalogue complexity, or growth plans |
| Platform engineering | Custom integrations, headless builds, ERP or fulfilment sync, performance work at scale | Stores where the site is the operation, not a brochure |
Most stores need the middle tier and are sold the first. The mismatch does not show up at launch — it shows up the first time you need something the theme did not anticipate.

The questions that reveal capability
Portfolios are curated. These questions are harder to stage.
"Can I see a site you built three years ago?" A launch screenshot proves design. A three-year-old site still running well proves engineering. Ask what has changed on it since, and who maintains it.
"What happens when WooCommerce releases a major version?" The answer you want describes a process: staging environment, test, deploy. The answer you do not want is silence, or "we update when something breaks."
"How many plugins will this build use, and why each one?" Every plugin is a dependency, a security surface, and a performance cost. A team that cannot justify each one is assembling rather than building.
"Who owns the code, and where does it live?" The answer should be: you own it, and it lives in a Git repository you have access to. If the code exists only on the production server, you are renting your own store.
"What happens to my rankings during the migration?" A team that has done this will immediately talk about redirect maps, URL preservation, and a pre-launch crawl. A team that has not will say "it will be fine."
"Who will I actually talk to?" Senior communication is the difference between a project that adapts and one that delivers what was specified six months ago whether or not it still makes sense.
Warning signs
- A quote without questions. Anyone who prices an ecommerce build before understanding your catalogue, integrations, and traffic is guessing, and the guess will be corrected later at your expense.
- No staging environment. Changes going straight to production is not a workflow, it is a habit that eventually costs a day of sales.
- Page builder as the architecture. Builders are fine for landing pages. A whole store built in one is slow, hard to change systematically, and locks you in.
- "We'll handle SEO after launch." URL structure, template markup, and internal linking are build decisions. Retrofitting them costs more than doing them right.
- No mention of performance. WooCommerce stores get slow in predictable ways. A team that never raises it has not run one at scale.
- The portfolio is all one vertical, and it is not yours. Not disqualifying, but ask how they will learn your category.
What it should cost, and why the cheap option is not
Ranges vary by market, but the shape holds: a theme configuration is a few thousand, a custom build is a multiple of that, and platform work is a multiple again.
The useful way to think about it is total cost over three years rather than the invoice at launch. A cheap build that needs replacing in eighteen months, plus the migration and the ranking recovery, routinely costs more than the build that would have lasted five years. That is not an argument for the most expensive quote — it is an argument for asking what happens in year two.
Ask specifically: what is included after launch, what is billed, and what happens when something breaks at 9pm on Black Friday.
WooCommerce versus the alternatives
Worth being straight about, because agencies rarely are.
WooCommerce gives you ownership, no revenue share, and unlimited customisation, at the cost of being responsible for hosting, updates, and performance. It suits stores that need the site to do something specific.
Shopify takes the infrastructure problem away and charges for it in fees and constraints. It suits stores whose needs fit the platform's shape.
The honest test: if you can list three things your store must do that a standard checkout flow does not, WooCommerce is likely the right answer. If you cannot, the platform question matters less than the execution.
What a good engagement looks like

Discovery. Catalogue structure, integrations, traffic and its sources, what breaks today, what the site must do that it currently cannot.
Architecture before design. URL structure, template types, and content model decided before anyone opens Figma. This is the step that decides whether SEO works.
Build in a repository, deploy from staging. Non-negotiable, and cheap to insist on.
A pre-launch crawl and redirect map if you are migrating. Every existing URL either survives or redirects to its closest equivalent.
Handover that includes documentation — how the custom pieces work, where the code lives, how to deploy.
A defined first year. What is covered, what is billed, and who answers the phone.
The evaluation checklist
- Seen a site they built three or more years ago, still running well
- Clear process for WooCommerce and plugin updates
- Every plugin in the proposed stack justified individually
- Code ownership confirmed in writing, in a repository you can access
- Staging environment part of the workflow
- Store not built inside a page builder
- SEO treated as a build decision, not a post-launch task
- Migration plan includes redirect map and pre-launch crawl
- Performance raised by them, not only by you
- Named senior contact, not only an account manager
- Post-launch terms defined: what is covered, what is billed
- Quote produced after questions, not before
Sources
- SEO Best Practices for Ecommerce Sites — Google Search Central
- Google Search Essentials — Google Search Central
- Creating Helpful, Reliable, People-First Content — Google Search Central
- Ecommerce Product Data and Content on Google — Google Search Central
- Intro to Product Structured Data on Google — Google Search Central
FAQs
Want this run against your store? Book a call with The Reach Bureau.