Online store development, 10 questions to ask a developer

# TagsWooCommerceSpeedSEO

The WPhost team23 Sep 202615 min read

You have collected offers for online store development, and at first glance they look alike. Every one says WooCommerce with Econt and Speedy delivery, and often "fast loading" too. The differences surface later, when a campaign overloads the server or a plugin update stops the orders.

Here are ten questions to ask every developer before you sign. The answers show what you are actually buying and who is responsible for the store after launch. There is a checklist at the end for ticking off the answers.

How will shoppers choose an Econt or Speedy office or locker?

Shoppers should be able to pick a courier office or locker right in the checkout and see the delivery price before they confirm. If they have to describe the office in an order note, you will get orders with mistakes and spend time on the phone sorting them out.

Econt and Speedy both have their own WooCommerce modules, and there are plugins from other developers too. Speedy's module, for example, offers delivery to an address, an office or a locker, and for lockers it does not allow the options to open and test the parcel. Ask the developer:

which module they will use, and why
whether the delivery price is calculated in the checkout itself
whether the module works with the block-based checkout, the default for new stores since WooCommerce 8.3
whether waybills are created automatically or by hand
whose name the courier contracts and the API credentials are in

The contracts and credentials should be yours. Ask for a test order with each courier and each delivery type before the store goes live. Setting up both modules is covered in How to set up Econt and Speedy shipping in WooCommerce.

Which payment methods will there be?

Cash on delivery is built into WooCommerce and can be limited to the courier shipping methods. For card payments you need a contract with a payment provider and its WooCommerce module. The contract is between you and the provider, and the developer connects the module to your account.

Ask:

which payment methods will be available at launch, and who sets them up
which provider the card payments will go through, and who signs the contract with it
whether card payments can be refunded from the WooCommerce admin
whether a test payment will be made in test mode before real payments start
whether the whole store runs over HTTPS

WooCommerce says most payment gateways require SSL and recommends HTTPS for the whole store, not only the checkout. Both payment methods, and the modules that suit a Bulgarian store, are covered in WooCommerce cash on delivery and card payments in Bulgaria.

How will invoices and other documents be issued?

Which documents you issue for an order, for cash on delivery and for a refund depends on your business and on the law, so we give no tax advice here. Agree the document flow with your accountant before the build starts, and put it in writing for the developer. It shapes the checkout, the customer emails and the links to other software.

Once you know what your accountant says, settle with the developer:

whether documents will be issued by a WooCommerce plugin or orders will go to your accounting software
where a shopper enters company details when they want an invoice, and which fields are required
how documents are numbered and what happens on a refund
who maintains the plugin or the integration if your accounting software changes

Think about the courier as well. Speedy, for example, offers a service where it issues the fiscal receipt on your behalf, but it needs a contract and an additional agreement with Speedy. Your accountant will tell you whether you need it.

How will products and stock from suppliers get in?

If you have few products, you can enter them by hand. If you have hundreds, or they come from suppliers, ask how they will get into the store and how prices and stock will stay current.

WooCommerce has a built-in tool for importing and exporting products as a CSV file. It can also update existing products, matching them by ID or SKU (the product code), and a number in the stock column turns on stock management. For a regular feed from a supplier or a warehouse system, the usual route is an import plugin or the WooCommerce REST API, through which another system creates and updates products.

Ask:

who enters the first products, descriptions and photos, and whether that is in the price
where the data comes from, for example a supplier's CSV or XML file, and how often it updates
what happens if the supplier's file is missing or wrong
whether every product has a unique SKU to match against
who maintains the integration when the supplier changes its file format

The questions about a wrong file and a new format look minor, but those cases need an answer before the integration goes live.

How fast will products and categories open on a phone?

From Google searches and ads, shoppers often land straight on a category or a product without going through the home page. So ask for the speed target to cover at least one category and one product with real photos, measured in PageSpeed Insights on mobile.

The good Core Web Vitals thresholds are 2.5 seconds or less for LCP, 200 milliseconds or less for INP and 0.1 or less for CLS. On a product page the largest element is usually the product photo, while INP matters when a shopper picks a variant or adds to the cart. According to Google, a lab score of 90 or more is good.

Ask separately about the cart and checkout. WooCommerce says the Cart, Checkout and My Account pages must not be cached, because they show data for one particular shopper. A cache does not help there, and speed depends on the server and the code, so ask to see a checkout with several products in the cart. Reading the report is covered in our guide to measuring site speed with PageSpeed Insights.

What happens to category SEO and the old addresses?

People search Google for specific products and for types of products. That is why each category needs its own title, description and a short text alongside the grid of photos. Ask about:

Product structured data. It lets Google show price, availability and reviews in results, and for pages where shoppers can buy there is a separate type called merchant listings. Google does not guarantee the richer result will appear.
Addresses. Google advises descriptive words in the path, for example /shoes/trainers rather than /?cat=17.
Filters. Filters by colour, size or price can create an endless number of addresses that Google crawls for nothing. Google describes how to limit them, so ask how they will be handled.
Old addresses. If you are replacing a store, every old product and category address should lead to its new one with a permanent redirect (301). Google advises keeping redirects for at least a year and warns of temporary ranking fluctuations.

How to switch without losing rankings is covered in our guide to redesigning a site without losing rankings.

Who will update the store and watch for vulnerabilities?

WooCommerce, the theme and every plugin get updates, some of them for security. According to Patchstack's annual report, 91% of the new WordPress vulnerabilities in 2025 were in plugins, and for 46% the developer had not released a fix by the time they were made public. A store holds customer and order data, so these risks hit it directly.

WooCommerce advises a current backup before every update, testing the update in staging whenever possible and never trying it straight on the live store. Ask:

who updates WooCommerce, the theme and the plugins after launch, and how often
whether every update goes through staging and a test order
whether someone checks the plugins for known vulnerabilities (CVE) every day
what happens when a vulnerable plugin has no fix yet
whether there are backups with tested restores
whether all of this is in the offer or under a separate maintenance contract

Will the store hold up under traffic peaks?

A campaign, a sale, a newsletter or an ad can bring many shoppers at once. A cache can take care of product browsing, but the cart and checkout are not cached, and every order puts load on the server and the database. Ask:

what hosting or cloud the store will run on, and who pays the bill
whether a load test has been run, and for how many visitors at once
what happens to an order if WooCommerce or the server does not answer at that moment
whether capacity can grow quickly, and who scales it

The third question is the awkward one. If the answer is "the shopper sees an error", that order is most likely lost. In the headless stores we build, the order goes into a queue and is not lost, even when WooCommerce does not answer. When a headless store is worth it is covered in our guide to choosing between classic WooCommerce and a headless store.

Who will own the data, the code and the accounts?

The store is your business, so everything it depends on should be in your name:

the domain and the hosting or cloud account
the Git repository with the code, and the right to use and change it
an account with the Administrator role in WordPress
the contracts with Econt, Speedy and the payment provider, along with the credentials for their systems
ownership in Google Search Console and administrator access to Google Analytics

The developer gets user access, which you can revoke at any time.

Customer and order data is your responsibility too. Ask where backups are kept, who can reach them and how you would get a full copy of the database if you part ways with the developer. If the developer will have access to personal data, agree in writing how they process and protect it. A lawyer can tell you whether you also need a separate data processing agreement.

How will changes be tested after launch?

A store keeps changing after launch. A new plugin, a new payment method or a change to delivery prices can break the checkout, and you usually find out only when the orders stop. Ask:

whether there is a staging copy with the same versions of WordPress, WooCommerce and the plugins
whether every change goes through Git and staging before it reaches the live store
whether a test order is placed after a change with every courier and payment method, in demo or test mode where one exists
whether there is a rollback plan if a change breaks something
who checks the first real orders after the change

A good answer describes the process step by step. "We are careful" is not a process.

Checklist

You have seen a test order with an Econt or Speedy office or locker chosen at checkout.
You know which payment methods there will be and who signs the payment provider contract.
The document flow is agreed with your accountant and written down for the developer.
It is clear how products get in and how prices and stock are updated.
Speed is measured on mobile for a category and a product, and the checkout has been tried with several products in the cart.
Categories have their own texts, products have structured data, and old addresses get 301 redirects.
Someone updates the store through staging and checks the plugins for vulnerabilities every day.
You know where the store will run and what happens to an order under heavy load.
The domain, hosting, code, contracts and Google accounts are in your name.
Every change after launch goes through staging and a test order, with a rollback plan.

What kind of online store development do you need?

If you sell a few dozen products and ship a few parcels a week, classic WooCommerce with the couriers' official modules is usually enough. The ten questions still apply, but the answers will be shorter.

As the store grows, we recommend a headless online store. The storefront runs on Next.js, while products and orders stay in WooCommerce. Speedy and Econt are in the checkout with office selection, and Kubernetes adds capacity during traffic peaks. We aim for 90+ for speed and 100 for SEO in PageSpeed Insights. If you already have a slow WooCommerce store, see our rebuild, where products, orders and customer accounts stay in WooCommerce and you keep working from the same admin.

Frequently asked questions

What should I ask a developer before ordering an online store?

Ask how shoppers will choose an Econt or Speedy office or locker, which payment methods there will be and how invoices and other documents will be issued. Ask how products and stock from suppliers will get in, how fast categories and products will open on a phone and what happens to SEO and the old addresses. The last questions are who updates the store and watches for vulnerabilities, whether it holds up under traffic peaks, who owns the data and accounts and how changes are tested after launch.

How should shoppers choose an Econt or Speedy office?

Right in the checkout, seeing the delivery price before they confirm. If they have to describe the office in an order note, you will get orders with mistakes and spend time on the phone. Ask for a test order with each courier and each delivery type before launch, and check that the module works with the block-based checkout, the default for new stores since WooCommerce 8.3.

Whose name should the courier and payment contracts be in?

Yours. The card payment contract is between you and the provider, and the developer only connects the module to your account. The same goes for the Econt and Speedy contracts and the credentials for their systems.

How should a developer measure an online store's speed?

In PageSpeed Insights on mobile, for at least one category and one product with real photos, not just the home page. Shoppers from Google searches and ads often land straight on a category or product. The good thresholds are LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, and since the cart and checkout are not cached, ask to see a checkout with several products in the cart.

How will products and stock from suppliers get into the store?

WooCommerce has a built-in tool for importing and exporting products as a CSV file, which also updates existing products, matching them by ID or SKU. For a regular feed from a supplier or warehouse system, the usual route is an import plugin or the WooCommerce REST API. Ask what happens if the supplier's file is missing or wrong, and who maintains the integration when the supplier changes its format.

Who should own the store's domain, code and accounts?

You. In your name should be the domain and the hosting or cloud account, the Git repository with the code and the right to use and change it, an Administrator account in WordPress, the contracts with Econt, Speedy and the payment provider, and ownership in Google Search Console and Google Analytics. The developer gets user access, which you can revoke at any time.

What happens to an order if the server does not answer during a campaign?

It depends on the store, so ask the developer exactly that. If the answer is "the shopper sees an error", that order is most likely lost. In the headless stores WPHost builds, the order goes into a queue and is not lost, even when WooCommerce does not answer.

How should changes be tested after the store launches?

Ask for a staging copy with the same versions of WordPress, WooCommerce and the plugins, and for every change to go through Git and staging before it reaches the live store. After a change there should be a test order with every courier and payment method, in demo or test mode where one exists, and a rollback plan if something breaks. A good answer describes the process step by step, and "we are careful" is not a process.

Sources