WooCommerce
Development Agency

A WooCommerce agency designs and builds the store, then owns the work a hosted platform would have done for you invisibly. WooCommerce is open-source software that runs on WordPress and on hosting you control, so the server, the updates, the backups, the security posture and the speed of the thing all sit inside the engagement instead of outside it.

That makes the job wider than a storefront. A store on this stack is a WordPress site with a commerce layer over it, which means one build has to satisfy a merchandiser, an editor, a finance team reconciling payments and tax, whoever picks and packs the orders, and a search engine reading the category pages. Serving one of those well at the expense of the rest is the usual reason a handsome store underperforms.

Why clients bring this particular work to us.

Content and commerce are one team here. Most stores end up on this platform because the business also runs a real publishing operation, and putting the shop with one vendor and the site with another places the seam in the worst available spot.

The extension stack gets argued about before anything is installed. Every plugin is a permanent dependency with its own release cycle and its own author. We would sooner write forty lines of code we can maintain than adopt a product carrying eleven features you will never switch on.

Hosting is treated as a decision instead of a default. The platform gives you the freedom to choose badly, and an underpowered plan beneath a real catalogue is the most common reason a store here feels slower than a hosted rival.

You hold the keys. Server, domain, database, repository, licences and payment accounts stay in your name from day one, and nothing in the build needs us to operate it.

Brand Vision has built on this stack since 2018, and there are more than fifteen years of practice sitting behind the founding team. 500+ projects delivered, plus a Clutch score of 5.0 assembled out of 64+ verified client interviews. You can see who actually does the work and go through stores and sites already shipped before you speak to anyone.

Ten service lines, scoped separately so you can buy the two you need instead of a package with eight things in it. Most engagements begin with one of the first three and grow from there.

1. Custom store design and build. A design system and template set instead of a purchased theme bent into shape, with category, product, cart and checkout treated as one connected path.
2. Migration to WooCommerce. Products, variations, customers, orders, reviews and URLs moved across from Shopify, Magento, BigCommerce, a legacy system or an older WordPress install.
3. Product architecture. Attributes, variations, grouped and external products, custom product types written in code, and the stock model sitting underneath all of it.
4. Custom pricing and checkout logic. Tiered and role-based pricing, quantity breaks, quotes, deposits, conditional fields and rules the standard flow does not express.
5. Extension selection and consolidation. Deciding what to install, removing what duplicates something else, and replacing anything the author has abandoned.
6. Performance and scalability work. Caching layers, database and query work, image handling, and the hosting conversation nobody enjoys having.
7. Payment and tax configuration. Gateway selection and setup, wallets and express payment, saved cards, tax rates or an automated calculation service, and the refund path your finance team has to live with.
8. Integrations. ERP, inventory, accounting, point of sale, warehouse and third-party fulfilment, plus marketing and support systems, built on the platform's own interfaces or through middleware where a direct connection is unwise.
9. Security and PCI scope. Hardening, access control, monitoring, and a written account of which parts of card-data compliance are yours and which belong to your provider.
10. Ongoing store support. Updates tested on a staging copy, backups verified off-server, uptime and error monitoring, and an allocation for the changes a growing store needs.

None of that is sold as a bundle. Where a store genuinely needs three of the ten, the proposal contains three, and where an existing store needs a diagnosis before anybody commits to a build, that is a scoped piece of work on its own.

Two honest notes on the edges. We do not resell hosting for margin, so the recommendation there carries no commission either way. And where the real constraint turns out to sit upstream of the store, in demand or positioning instead of in the shop, the answer lives elsewhere in the full range of services and usually looks like marketing work for a consumer brand instead of a rebuild.

WooCommerce is not a platform you sign up for. It is open-source software that turns a WordPress site into a store, which means everything true about WordPress becomes true about your shop. That one fact explains both halves of the trade, and buyers who miss it are usually surprised by the same things later.

The inheritance runs in both directions at once. You get the editorial model, the taxonomy system, a role structure running from administrator through to subscriber, the template layer and an enormous population of developers who already know it. You also get the obligation, meaning core releases, PHP version upgrades, extension updates and the backups nobody values until the morning they need one.

What you gain by controlling the environment.

• Hosting is your choice, so the store can sit on a server sized for its actual traffic, in a country your data rules require, on a database your own people can query.
• Product and category URL bases are configurable in the permalink settings, which matters enormously when you are moving from somewhere the paths were fixed.
• Pricing and checkout behaviour can be modified in ways a hosted checkout does not permit, which is the whole reason a lot of stores are here.
• The software itself is free. Your costs are hosting, extensions and gateway fees, which is a different cost shape and not automatically a cheaper one.

What you take on in exchange.

• Uptime and speed become your responsibility, and the platform will not stop you making a bad hosting decision.
• Security patching runs on a real clock, because a disclosed vulnerability in something you run is public the same week.
• Backups, staging and a tested restore are yours to arrange.
• Capacity for a promotion is yours to plan, since nobody is quietly adding servers on your behalf during a sale.

So it suits a business with a substantial content operation, unusual product or pricing requirements, or a genuine hosting and data constraint, and a named person who owns the stack. A retailer with physical locations often lands here for the same reason, since the content depth that supports local search already lives on the same site. Where none of that applies, the hosted alternative is usually the better answer and Q6 says so plainly. The platform sits alongside a standard WordPress build in every other respect.

Two variables decide the budget and neither one is page count. How much of the store has to behave differently from the default, and how much data has to arrive from somewhere else. Everything else is detail.

Where the time goes on a typical build.

• Discovery and technical planning, one to two weeks. Catalogue shape, the commercial rules, the systems that have to connect, the hosting target, and an inventory of what exists today if anything does.
• Architecture and design, three to five weeks. Product model and taxonomy first, then templates and the purchase path, resolved as prototypes before code.
• Build, four to eight weeks. Theme and design system, product import structure, custom logic, the extension set, and each integration built and tested against real records.
• Payments, tax and data, running alongside the build. Gateway setup in test mode, tax configuration, and the migration rehearsals if you are moving.
• Launch and the month after, roughly two weeks of work spread across four. Cutover, redirect verification, live payment testing, then monitoring while real orders reveal what a test order could not.

A straightforward store on a clean catalogue lands around ten to fourteen weeks. A migration carrying unusual product logic and two or three system connections runs four to six months. Those are typical ranges and not a quote.

What actually moves the number. Catalogue shape, since a hundred simple products and a hundred products with sixty variations each are different projects. How many pricing and checkout rules depart from the default, which is the single largest driver on this platform. The number of integrations, because a documented interface and a twenty-year-old system with a nightly file drop are different orders of difficulty. Product photography and original copy, frequently the largest line and always visible. Whether an existing WordPress site is being kept, extended or replaced. And how many people hold approval, which predicts a slipping schedule more reliably than anything else in the design and build practice.

Every proposal breaks the work into lines you can challenge one at a time, and where a smaller version of the project is the honest recommendation you will hear that instead of a larger number. To find out which band you are in, tell us about the store you have now and the read arrives before anything gets scoped.

Badly hosted, yes, and measurably slower than a hosted platform doing the same job. Properly hosted and properly built, no. That is the honest answer, and this platform hands you the ability to get it wrong in a way a hosted one does not.

Where the slowness actually comes from, in rough order of how often we find it.

• Hosting sized for a blog. A store spends much of its day serving requests that cannot be cached, so the number of concurrent PHP processes, the disk speed and the database resources matter far more than they do on a brochure site.
• No object cache. Object caching keeps the results of repeated database lookups in memory, using Redis or Memcached, instead of asking the database the same question on every request. Its absence is the most common single finding.
• Page caching applied where it must not be. Cart, checkout and account pages are personal to one visitor and have to bypass the full-page cache. Configure that carelessly and you either leak one customer's cart to another or leave your heaviest pages uncached.
• The extension stack. Each addition brings its own stylesheet, script and queries, loaded site-wide by default even when the feature appears on two pages.
• Database weight. Options loaded automatically on every request, expired temporary records that never got cleared, orphaned tables left behind by removed plugins, and order queries running against the general content tables instead of the dedicated order tables the platform now offers as High-Performance Order Storage.
• Images and the product grid. Oversized uploads, missing responsive sizes, and category pages rendering more products than anybody scrolls to.
• Scheduled tasks running on visitor page loads, which is the default behaviour and is unreliable on a quiet site and expensive on a busy one. A real server-side scheduler fixes both.

Scalability is a separate question from speed. A store that is comfortable on ordinary Tuesday traffic can fall over during a promotion, and the failure usually appears at checkout, where requests cannot be cached and every order writes to the database. So we load-test the purchase path before a sale instead of after one, and stop order processing in the admin from competing with the storefront for the same resources.

Speed is a search issue too, and the field measurements sit with the rest of the technical foundation. Very large catalogues bring their own indexation and crawl problems, which is large-site search work instead of a caching problem. Where you want the diagnosis before committing to anything, a scoped assessment stands on its own.

Often enough that we talk people out of it most months, and we would sooner lose the build than hand over a store nobody on your side can run. Four situations, each with a better answer attached.

When nobody in your business will own the stack. This is the big one. If there is no internal technical owner and no appetite for a support arrangement, self-hosting becomes an unmanaged liability within a year. Shopify takes the hosting, the patching, the uptime and most of the card-data problem off your desk, and for a small team selling a straightforward catalogue that trade is obviously correct. We recommend it more often than we recommend this platform.

When the site is mostly a marketing site with a little selling attached. A dozen products behind a site whose real job is credibility does not justify a commerce stack and its maintenance. Webflow suits that case better, because design control and a non-technical team publishing often are what the project actually needs, and the selling is a small component instead of the point.

When the requirement is a product instead of a shop. Multi-vendor marketplaces with payouts, usage-based or metered billing, a quoting engine with real underwriting behind it, or a catalogue that is not really a catalogue. Bending commerce plugins into that shape produces something fragile and expensive, and a custom build is the honest route.

When you already have a store that works and the complaint is aesthetic. Replatforming a functioning store because leadership is bored of it is the most expensive way to buy a new visual identity. The cheaper version is a template and content pass on what you have. Where you want that judgment made on evidence instead of opinion, an audit will answer it inside two or three weeks, for a small share of what the replatform would have cost.

What makes it the right choice is narrower than the internet suggests. Somebody owns the stack. There is a real content operation the store should live inside. The product or pricing model genuinely needs behaviour a hosted checkout will not allow. Or hosting location and data control are requirements rather than preferences. Two of those four is usually enough. None of them and you are buying flexibility you will pay for and never use.

A migration is a data project with a design project attached, and running them in that order is what keeps the launch boring. The design decisions are easier once you know exactly what is coming across and what refuses to.

The sequence starts with an inventory instead of an export. Every product with its variations and stock records, every customer, every order with its tax and shipping breakdown, media, reviews, existing redirects, and the list of systems currently connected to the old store. Then a field-by-field mapping document, then a test import into a staging copy, then a reconciliation that counts records on both sides and compares totals until they match. Only after that does anybody schedule a cutover, and the cutover itself carries a short freeze on content and a plan for orders placed during the window.

What does not transfer cleanly, and all of it is easier to tell customers about in advance.

• Customer passwords. Stored hashes are not portable between systems, so customers reset on first login. That needs a communication plan instead of a support queue on launch day.
• Active subscriptions and saved cards. Stored payment credentials belong to the gateway, so keeping the same processor is far easier than changing one, and changing usually means asking customers to re-authorize.
• Discounts and promotion rules. These rarely map one to one and are better rebuilt deliberately than approximated.
• Anything a third-party app was providing. A feature delivered by an app on the old platform is not a data export. It is a requirement to rebuild, and it belongs in scope at the start.
• Order history detail. Line-item tax, shipping and refund breakdowns often arrive flattened, which finance notices long before anybody else does.

On URLs, this platform is unusually forgiving. Product and category bases are configurable, so where the old paths are earning rankings they can frequently be preserved instead of redirected wholesale. Where they cannot, each retired address receives one specific destination, and the whole map runs against a crawl of the old site before cutover and again once the new one is live. That is handled by the people who do replatforming work and category and product search rather than added to a launch checklist, and rankings get benchmarked beforehand so the comparison afterward is real. The honest disclosure is that even a clean move can fluctuate for a few weeks while search engines recrawl, which is why the technical baseline is recorded before anything changes.

Four product types ship with the platform and a developer can register more, and getting the model right at the start is worth more than any amount of tidying afterward. A product model is the one decision that is genuinely expensive to reverse once orders exist against it.

Working from the simplest arrangement to the heaviest.

Simple. One item, one price, one stock record. Most catalogues are mostly this and should stay that way.

Variable. One product carrying attributes, with a variation generated for each combination and its own code, price, stock level and image. Size, colour, material and finish can all be attributes on the same product at once. There is no fixed variant ceiling or option-count limit of the sort hosted platforms impose, so the constraint is performance and merchandising sense instead of a number in the documentation. Two thousand variations is permitted and is usually a modelling mistake dressed up as flexibility.

Grouped. A parent page that presents several separately purchasable products together, which suits ranges, sets and spare parts far better than forcing them into variations.

External. A product presented on your site that completes the purchase somewhere else, useful for catalogue depth you do not stock yourself.

Custom types written in code. Subscriptions, bookings, memberships, licences, made-to-order items, configurable assemblies, and products priced by weight, length or area. This is where the platform separates itself, and it is also where an undisciplined build becomes unmaintainable, so each custom type carries documentation explaining what it does and why.

One technical decision underneath all of this decides how usable the catalogue feels. Attributes defined globally behave as taxonomies, which is what allows filtering and layered navigation across the whole catalogue. Attributes typed into a single product do not. Stores arrive with hundreds of one-off attributes and no way to filter anything, and correcting it later means touching every product.

Two things get planned alongside the model. Which filter combinations are allowed to be crawled and indexed, which is one of the highest-impact calls in category and product visibility and easy to get badly wrong. And whether specifications sit in structured fields a machine can read, since that is what determines whether your products appear in AI-assembled answers. Catalogues with weights, measures, allergens or batch detail need more of this than most, which is why food and drink businesses tend to need the heaviest modelling work.

This is the main reason a store ends up here instead of somewhere easier, and it is the one thing a hosted checkout genuinely will not let you do. Prices and checkout behaviour are modifiable in code, so the rules can follow your commercial model instead of your model bending to fit the software.

Logic we have built on this platform, from the common to the awkward.

1. Role-based and customer-specific pricing. Wholesale, dealer, member and staff prices across one catalogue, with the right figure shown to the right logged-in account and invisible to everybody else.
2. Quantity breaks and tiered rates, applied per product, per category or per customer group, recalculating as the cart changes.
3. Pricing by measurement. Sold by weight, length, area or volume, with a calculator on the product page and the resulting figure carried accurately into the cart and the order.
4. Quotes, deposits and part payments. A cart converted into a quote for approval, or a deposit taken now with the balance collected later.
5. Checkout field changes. Fields added, removed, reordered, made conditional on something else, or validated against an external service such as address lookup or a tax registration check.
6. Conditional shipping and payment availability. Methods shown or hidden by product, weight, destination, order value or account type.
7. Order-level rules. Minimum orders by customer group, purchase limits, restricted products, and orders held for approval before they are accepted.

Business-to-business selling is where this stops being optional, since dealer pricing, net terms and approval chains are ordinary requirements in B2B and wholesale and unavailable on most hosted checkouts without compromise.

Now the honest ceiling. All of it attaches at defined extension points in the code, which is durable. Achieving the same result by overwriting templates or editing a plugin directly is not, and inherited stores are full of the second kind. There are also two checkout implementations in circulation, an older one and a newer block-based one, and they do not share an extensibility model, so a customization written against one does not automatically carry to the other. Choosing which a store uses is a real decision at kickoff instead of a preference. And every rule you add is a rule somebody tests on every future update, so each one is documented with the reason it exists. The failure mode we are avoiding is a store nobody dares to update, which is a custom engineering discipline problem more than a platform one. Whether a checkout step earns its place at all is answered by watching real customers in behavioural research instead of by argument.

Fewer than you have. Most requirements are met by an extension you already own configured properly, or by a small amount of code that adds no dependency at all. Extension sprawl is the most common problem in a store we inherit, and it is almost never one bad decision. It is thirty reasonable ones.

How the audit runs. Every active plugin gets listed with what it does, when the author last shipped an update, whether anything on the site still depends on it, what it loads on the front end, and whether something else is already doing the same job. Stores routinely discover two review plugins, three form builders, a page builder used on four pages, an abandoned currency switcher from a campaign years ago, and code left behind by a plugin somebody deactivated but never removed.

Five tests each survivor has to pass.

1. Something on the site actually uses it. Not planned to, not used once. Currently.
2. The author is still maintaining it, and where the function is load-bearing there is a commercial licence with support behind it instead of a free plugin holding up your revenue.
3. It loads only where it is needed instead of adding assets to every page including checkout.
4. It is not overlapping with another extension or with something the platform already does.
5. You could survive its disappearance. Anything that would take the store down if the author walked away gets either replaced or a documented contingency.

Integrations are a different decision entirely. Connecting to a system of record, meaning an ERP, an inventory platform, accounting, a point of sale, a warehouse or a third-party fulfilment provider, is not a plugin question. The questions are which system owns stock, which owns price, which owns the customer record, what happens when two of them disagree, and whether each sync fires on an event or runs on a schedule. The platform provides an interface for programmatic access and webhooks for event-driven updates, and scheduled work needs a proper server-side scheduler and a queue instead of the default arrangement. Where a vendor ships its own connector, we test it against your real order volume before trusting it, because something that behaves on fifty orders a day can collapse at five hundred. A vendor with a documented, modern interface makes this straightforward, and technology companies usually have one. Older operational software rarely does, and the honest answer there is middleware.

Inherited stores get this assessment before any quote, the same way a replatforming decision does, and the extension list is where the surprises live on a store of any age.

Payments are a contract before they are a configuration, tax is a registration question before it is a settings question, and how much of card-data compliance lands on you depends entirely on how card details reach your provider. Three separate problems, routinely bundled together and then handled badly.

On payments. Gateway choice usually follows a contract you already hold, and most acquirers a merchant is likely to be using have an integration for this platform. Where the only option is a third-party build, that is worth reading closely before your revenue depends on it. Beyond the connection itself, the work is wallets and express payment so mobile buyers are not typing card numbers, saved cards where repeat purchase justifies it, sensible handling of declined and failed payments, refunds and partial refunds that reconcile properly, and testing every path in the provider's sandbox before launch and again with a live card afterward.

On tax. The platform will calculate whatever you configure, which is precisely the risk. You can maintain rate tables yourself or connect an automated calculation service, and either works once the underlying question is settled, which is where you are registered and obliged to collect. Selling within Canada means a federal component plus provinces that operate their own separate sales tax with its own rules. Selling into the United States means state-level obligations triggered by thresholds instead of by physical presence. Registration first, configuration second. We are not your accountants and we do not decide where you are registered.

On PCI scope. Payment card industry rules apply to anybody handling card data, and the amount of your environment that has to be assessed depends on the route you choose. Payment fields hosted by the provider in an embedded frame, or a redirect to their page, mean card numbers never touch your server. Tokenization means you store a reference instead of a card number. Collecting card details on your own pages and passing them onward widens your scope substantially. Even on the narrow route, your site still affects the security of the payment page, so the environment matters. We build to keep scope narrow and we are not a qualified security assessor, so which assessment applies to you is confirmed by your acquirer or an assessor and not by an agency. Cross-border selling is ordinary for the businesses we work with, and the teams in Toronto and Chicago see both sides of it regularly.

You do, or we do under a support arrangement, and the only arrangement that reliably fails is nobody. Self-hosting is a genuine advantage and a standing obligation at the same time, and the obligation does not care whether anybody accepted it.

What a support arrangement covers.

• Core, commerce, theme and extension updates, applied to a staging copy first and checked against the paths that earn money before they reach the live store. Updating a store directly in production is how a Tuesday becomes a bad week.
• Security patching on a schedule that matches disclosure. The way in is almost always an out-of-date extension or theme instead of the core software, and once a vulnerability is published the window closes fast.
• Access control and hardening. Real accounts for real people, administrator rights kept scarce, two-factor authentication, file permissions, and a web application firewall in front of the login and checkout.
• Backups held off the server and restored on a test schedule, so you know both that the restore works and how long it takes. A store also needs its database backed up more often than a brochure site, because an hour of lost orders is unrecoverable.
• Uptime, error and payment monitoring. A gateway that quietly stops authorizing looks completely normal from the front end, which is why it gets watched separately from uptime.
• Database and performance upkeep, since stores accumulate weight steadily as orders, sessions and logs pile up.
• A monthly allocation for content changes, small improvements and the merchandising work a growing catalogue needs.

Plans get sized against how much the store actually moves. A catalogue that rarely changes carries a far lighter arrangement than a store running promotions and adding products every week, and the fee should follow that instead of charging everybody for a service level most of them never reach. Support is a choice and never a condition of the build. Documentation is written so your own engineers or a different agency could pick the store up without us, and we will run that transfer properly if that is what you decide. The work is done by developers on staff instead of subcontracted, which is also why the roles we hire for lean engineering.

On ownership, nothing here is held. Accounts, code, database, design files and licences are in your name throughout, the same standard applied to any WordPress project we deliver. If you want a read on the state of a store you already have, including what its current maintenance situation is quietly costing, send us the details and you will get a straight assessment.