A delivery order is not an ecommerce checkout
A client asks for online ordering. You know WordPress, so you reach for WooCommerce, add a shipping plugin for the delivery fee, an add-on to push orders somewhere the kitchen will see them, and some CSS to make the product grid look like a menu.
It works. It demos well. And then you maintain it.
Where the model stops fitting
WooCommerce models a store that sells products and ships them. Delivery is a different shape, and the gap shows up in places you do not control:
Time. An ecommerce order is valid whenever it arrives. A delivery order is only valid while the kitchen is open. Woo has no concept of business hours, so you bolt one on, and now you own the edge case where someone loads the page at 22:58 and checks out at 23:01.
Distance. Shipping plugins price by weight and zone, because that is what carriers charge on. Delivery prices by how far the driver rides. You can approximate zones with postcodes until a client points out that half a postcode is three blocks away and the other half is across a river.
Order state. Woo statuses describe fulfillment of a shipment: processing, completed, refunded. Delivery statuses describe a kitchen: confirmed, preparing, out for delivery, delivered. You can rename them. You cannot make the rest of the ecosystem understand what you meant.
The cart itself. Ecommerce carts are built for browsing, saving, and returning later. A delivery cart is filled in two minutes by someone who is already hungry, on a phone, and will abandon at the first extra step.
Each gap has a plugin that closes it. That is the trap: none of them is unreasonable on its own.
The cost is not the build, it is the multiplication
One site with four plugins is fine. The problem is that this is your product now.
Every WooCommerce release is a compatibility question across four vendors. Every client is another copy of that surface. When a shipping plugin changes how it calculates a zone, you do not find out from a changelog, you find out from a client whose delivery fee went to zero on a Saturday night.
And you are carrying an entire ecommerce engine, with its inventory, tax, coupon, and variation machinery, to sell a hamburger.
What the alternative looks like
MyD Delivery is a single plugin that models delivery directly: products and categories, delivery zones, order management, WhatsApp notifications, and payments, with no WooCommerce underneath. The core is free on WordPress.org, so replicating a setup across clients costs nothing per install, and there is one vendor in the compatibility question instead of four.
Add-ons are billed by usage rather than per site, which matters when you host many small clients: a store with three orders a day does not pay like a store with three hundred.
When WooCommerce is still the right answer
If the client genuinely sells products and delivery is one fulfillment option among several, stay on Woo. If they need real inventory, variations, coupon campaigns, or the plugin ecosystem around any of those, stay on Woo. Adapting it is only a mistake when delivery is the whole business and you are paying for an ecommerce engine you never use.
The question worth asking before the first install is not “can WordPress do this”. It is “how many of these am I going to be maintaining in two years, and what breaks when one of them updates”.