WooCommerce development
Stores built on WordPress, where the checkout is yours to change.
WooCommerce builds and rebuilds: catalogue structure, custom product types, checkout flow, payment and shipping integrations. Written as a child theme and plugins, so updates do not overwrite the work.
Project pricing
From $5,250
That covers the audit and the fixes that make the stack maintainable again. A rebuild with a block checkout, custom logic and a data migration runs to $19,000.
Send the brief and get a number back.
Describe the projectIt works until an update, and then nobody knows which plugin
The store runs on thirty-odd plugins that were each installed for one good reason. One day an update breaks checkout, or the orders screen, or the tax line, and there is no staging copy to test on. So the update gets rolled back and then stopped altogether, and the store settles into a version that works today. From there it drifts: the gateway stops receiving fixes, one plugin still writes orders the way WooCommerce did years ago, and every new requirement costs more than the last because nobody can say what will break.
What the work covers
The stack read before anything is written
Which plugins touch the order lifecycle, which are declared compatible with the current order storage, which still assume the old checkout, and which are installed but doing nothing. That list decides whether your store needs work or needs a plan, and it comes before an estimate rather than after one.
A checkout that survives the block migration
The block-based cart and checkout replaced the shortcode pages that defined WooCommerce for a decade. Gateways, custom fields and shipping logic written for the old page do not carry over on their own. Each one either moves to a supported equivalent or gets a block integration written for it, and the ones that cannot move get named early.
An update path you will actually use
A staging copy that mirrors production, backups that have been restored at least once, and a routine for applying updates that does not depend on courage. Stores stop updating because updating is frightening, not because they decided to run old software. Removing the fear is what keeps the store current.
Why it is done this way
Owning the stack means owning the update path
The trade for not paying platform fees is that nobody upgrades the store for you. A hosted platform migrates its own checkout and tells you afterwards. WooCommerce waits for you, and the store keeps taking orders while it falls behind, which is the dangerous version because nothing looks wrong. The work that keeps a self-hosted store cheap over five years is unglamorous and scheduled.
Order data no longer lives where old code expects
Since WooCommerce 8.2 in October 2023, new installations store orders in dedicated tables rather than in the WordPress posts table, and the platform has kept building on that. Plugins that query the old tables directly, or that were abandoned before the change, behave in ways that are hard to diagnose from the admin. Checking that before quoting work is the difference between a fixed price and a discovery.
How it runs
A read of the installed stack, the order storage mode, the checkout type in use, the hosting and where backups actually go.
A written plan in two halves: what has to change for the store to be maintainable, and what you want it to do that it currently cannot.
The work happens on staging with a copy of real orders and products, because plugin conflicts do not reproduce on a clean install.
Deployment in a window you choose, with the rollback path tested rather than assumed, and a test order placed on production afterwards.
A maintenance rhythm agreed in writing: what gets updated, how often, who looks at it, and what happens when something breaks at two in the morning.
Background
What running WooCommerce actually involves now
Orders are not where older code expects them
For most of WooCommerce's life an order was a WordPress post with metadata attached, which was convenient and did not scale. High-Performance Order Storage moved orders into dedicated tables, and since version 8.2 in October 2023 that has been the default for new installations, with existing stores migrating on their own schedule through a compatibility mode that synchronises both layers. The platform has kept building on it since. What this means practically is that any plugin querying the old tables directly, or abandoned before the change, is now a liability you can only find by looking.
The checkout changed underneath the ecosystem
Block-based cart and checkout replaced the shortcode pages that defined WooCommerce for a decade. The blocks are better for editors and for the platform's roadmap, but a decade of extensions was written against the old page: gateways with custom forms, plugins adding fields, shipping logic hooked into the classic template. Some vendors migrated, some shipped partial support, some disappeared. Any store planning a checkout change is really planning an inventory of which extensions came along.
The plugin stack is the real cost
Self-hosted commerce trades a platform fee for a maintenance obligation, and the obligation is mostly the plugins. Every one is a separate release schedule, a separate security posture and a separate business that may or may not exist in three years. The stores that stay cheap over five years are the ones that keep the stack small on purpose, replace anything abandoned before it becomes urgent, and know which extensions the checkout genuinely depends on.
Hosting is part of the product
On a hosted platform, infrastructure is somebody else's problem. On WooCommerce it is yours, and it shows up as page speed, admin speed and how the store behaves on a campaign day. Object caching, a database that can carry a growing order table, sane cron handling and a staging environment are not optional extras, they are the difference between a store that grows and one that gets slower every quarter. Six WooCommerce storefronts in the portfolio run across nine live domains, into Poland, Ukraine, Mexico, Brazil, the United States and worldwide.
Describe the project
Tell us what you have and what should change. Within two working days you get a written calculation: the scope broken into parts with a price against each, or the questions needed to write one. No discovery call in between.
Questions
WooCommerce work, asked and answered
It is a real migration, so it is planned rather than clicked. There is a compatibility mode that keeps both storage layers in sync during the transition, which is what makes the move reversible. The risk is not the migration itself, it is a plugin in your stack that reads orders the old way and was never updated. That is found first, on staging, with your real order volume.
Eventually yes, because that is where the platform is investing and where new features land. Whether now is right depends on what your current checkout does. A store with a payment gateway and two custom fields moves easily. A store with conditional logic, a booking flow or a gateway that never shipped block support needs those answered first, and the honest answer is sometimes to wait one more release.
The count matters less than the overlap and the maintenance. Three plugins doing one job each is healthier than one doing everything badly. What actually hurts is plugins with no release in years, two plugins fighting over the same hook, and anything in the checkout path that only one person on the internet understands. The audit names those rather than counting.
Sometimes, and you will be told so. Shopify makes sense when you want the platform to carry the maintenance and you can live inside its rules, particularly at checkout. WooCommerce makes sense when the product model, the pricing logic or the integrations are yours in a way no hosted checkout allows, and when somebody is going to maintain it. Choosing Woo and then not maintaining it is the expensive path.
Usually it is hosting, caching and the plugin stack rather than the platform. A Woo store on shared hosting without object caching, with an unindexed order table and a page builder on every template, will be slow regardless of how the code is written. Performance work starts with measurement on the real site, not with a rewrite.