What a first WooCommerce store actually needs configured before it takes an order

The settings that break a first store are the boring ones. A customer reaches checkout, the address does not match any shipping zone, the page says no shipping methods are available, and nobody finds out because the first person to try it was a real buyer.

Below is the set of things that have to be right for money to come in, then the things that can wait until there is an order history to argue with.

Products: enough to sell, not a catalogue project

Enter a real price and, if you track units, tick Manage stock on the product itself, or enable stock management store-wide under Products → Inventory. Without that tick, stock never decrements and you will oversell the one item you have.

Weight and dimensions only matter if a shipping method calculates from them. If you are charging a flat rate, skip them for now; adding them later does not change anything already configured.

Use a variable product only when price, stock or image genuinely changes per variant. "Gift wrap" is a checkout field, not a variation, and each variation is another thing that can be out of stock at the wrong moment.

Two or three categories with a purpose. Categories are navigation; a taxonomy built before the tenth product is a taxonomy you will redo.

Shipping: the zone is the part people get wrong

A shipping zone matches the customer's address. If no zone matches, WooCommerce shows no shipping methods at all and the order cannot be placed. So the minimum is one zone that covers everywhere you will actually ship, even if it is the catch-all "rest of the world" zone with a flat rate on it.

• One zone, one flat rate, for the countries you really deliver to.
• Free shipping as a second method in the same zone, with a minimum order amount, if that is the offer.
• Local pickup if you hand-deliver or the buyer collects.

Do not build a dozen zones from guesses about what shipping will cost next year. Every zone you add is another one whose rates go stale silently.

Tax: one decision before any rate exists

Decide whether your entered prices include tax or exclude it, before you type prices. Changing that setting later re-computes every price shown on the front end, and the catalogue you checked last week is suddenly wrong.

Then enable tax calculation and add standard rates for the countries you sell into. If you sell across borders, get local advice on registration thresholds before you invent rates; the software will accept any number you give it and print it on an invoice.

Payments: one gateway live, tested end to end

Enable a single card gateway and complete a real transaction for a small amount, then refund it. A sandbox run does not exercise the same path as a live authorization, and the first failed live payment is a bad way to learn that.

Confirm the site is served over HTTPS before the gateway goes live, and read the order notes after the test. An order that looks paid in the admin but has an empty gateway response is usually a callback that never arrived, and no amount of theme work fixes it.

The two emails, tested in a real inbox

The customer receipt and the new-order notice to you are separate emails and both can fail independently. Test both, delivered to an inbox you actually read, with the from-address on your own domain.

If neither arrives, the site cannot send mail at all. That is a hosting and DNS problem, not a store setting, and it is worth knowing before launch rather than after the first support message.

Pages that have to exist

Refund and returns policy, privacy policy, terms, a contact route, and a statement of delivery times. These are jurisdiction-specific. Read them against your local consumer rules instead of copying another store's text.

Read the settings back before you announce

A quick read-only pass with WP-CLI, which is faster than clicking through screens and harder to misread:

wp option get woocommerce_currency
wp option get woocommerce_default_country
wp option get woocommerce_calc_taxes
wp option get woocommerce_prices_include_tax
wp option get woocommerce_enable_guest_checkout

PREFIX=$(wp db prefix)
wp db query "SELECT zone_name FROM ${PREFIX}woocommerce_shipping_zones;"
wp db query "SELECT zone_id, location_type, location_code FROM ${PREFIX}woocommerce_shipping_zone_locations;"

What you are looking for: taxes actually enabled, the include/exclude decision matching your price list, at least one zone with at least one location that covers your buyers, and guest checkout set to whatever you decided rather than the default you never looked at.

The test order, run twice

Place an order on a phone, with a real card, for the cheapest thing you sell. Then check:

• stock went down by one, and went back up after the refund;
• both emails landed, and the customer one is not in spam;
• the thank-you page shows the order and the admin shows the same total;
• the shipping line matches the zone you expect for that address.

Then do it again from a country in your second zone, if you have one. Cross-border is where zone overlap and tax display disagree, and it is better to find that on a test order than on a real one.

What can wait

Multi-currency, a second language, subscriptions, reviews, wishlists, a coupon engine beyond one launch code, loyalty points, warehouse or accounting sync, per-product shipping rules beyond what a flat rate handles, abandoned-cart tooling, A/B testing, and a blog.

None of these are bad. Each of them adds a surface that can break during a checkout, and none of them are needed to prove that the store can take money and deliver the thing.

The minimum is small and unglamorous: money in, correct totals including shipping and tax, stock that reflects reality, and a buyer who gets told what happened. Everything else is a second release.