Development
WooCommerce developer: shops, payments and integrations
A WooCommerce shop that is slow, or that needs somebody to retype every order into the accounting system, is losing money in a way you can measure. I build shops, fix the ones that are leaking, and connect them to the systems that should already know about the orders.
When this makes sense
- The shop is slow on a phone and you can see it in the checkout numbers
- Orders are being copied into e-conomic or Billy by hand every week
- You need something the standard plugins do not quite do, and the plugin that claims to do it broke the theme
- Stock is right in the warehouse system and wrong in the shop, or the other way around
- Checkout works for you when you test it, and customers keep reporting that it does not for them
How it works
- 01
Measure
Real numbers first: load time on an actual phone, where the checkout drops people, and what the plugin stack is costing you per page.
- 02
Fix and build
Speed work, checkout work, or the integration you need — priced and agreed before it starts, and staged so the shop never takes an untested change.
- 03
Watch it
Monitoring on the shop and on the integrations, because a sync that stopped on Friday should not be discovered by a customer on Monday.
What the work covers
- Checkout and payment flow work, including Danish payment providers
- Integration to accounting and inventory, with retries and alerts when a sync fails
- Speed: the plugin weight, image sizes and caching that decide mobile load time
- Custom product logic where variations and standard plugins run out
- Shipping and fulfilment integrations, including the Danish carriers
- VAT and invoicing details that have to be right for the bookkeeping to reconcile
- Migration from another platform, with products, customers and order history
- Tracking and consent set up correctly, so the numbers are accurate
- Product markup carrying price, stock status and delivery time, so Google and the AI assistants read the range correctly
Where a WooCommerce shop actually loses money
Three places, in the order they are usually worth fixing. The first is mobile load time, because most Danish shop traffic is on a phone and the checkout funnel drops people in proportion to how long the page takes. The second is the checkout itself: a field nobody needs, a shipping calculation that only appears at the last step, or a payment method that fails silently on one card type. The third is the hour a week somebody spends retyping orders into the accounting system, which is a working week a year that shows up as staff cost rather than as a shop problem.
None of the three is visible from the admin dashboard, which is why they persist. Order volume looks fine, the shop is up, and the loss is spread thinly enough that nobody attributes it to anything. So the work starts with measurement on a real device and a real connection, not with a redesign.
Integrations, and what makes one hold up
Connecting a shop to e-conomic, Billy, a warehouse or a shipping provider is straightforward on the day it is built. What separates an integration that lasts from one that quietly stops is what happens on the bad days: the API is down for twenty minutes, a product has no VAT code, a customer address will not validate, or somebody refunds an order that was already booked.
So an integration here is built with retries and a queue rather than a synchronous call, an error path that names which order failed and why, and an alert that reaches a person. The failure mode I am designing against is the one where a sync stopped on a Friday and was discovered by a bookkeeper the following month, because that is the version that costs real money to unpick.
An integration is usually delivered in 1–2 weeks. It is priced separately from the shop itself so you can see what the plumbing costs and decide on it separately, and both prices are agreed in writing before the work starts.
Speed work, and what it is reasonable to expect
Most slow WooCommerce shops are slow for ordinary, fixable reasons: overlapping plugins doing the same job, images served at desktop resolution to phones, no caching in front of pages that never change, and a theme that loads the whole shop’s JavaScript on the front page. Fixing those is measurable work with a measurable result, and I measure before and after so the improvement is documented.
What speed work will not do is turn a shop with forty plugins into a fast shop while keeping all forty. At some point the recommendation is to remove things, and that is a commercial decision rather than a technical one, so it comes to you as a list with what each one costs in page weight. You decide what stays.
Danish payments, shipping and moving from another platform
A Danish shop has to accept MobilePay and Dankort, and that happens through a payment gateway such as QuickPay, Nets or Frisbii, which also handles subscriptions and cards saved for the next purchase. Shipping usually runs through Shipmondo or a direct connection to GLS, PostNord or DAO, so labels and tracking are created automatically as soon as an order is paid.
Many shops come to WooCommerce from Shopify, DanDomain or an older solution, and the move is more than copying the products. Customers, order history, variants and images have to come along, old addresses need 301 redirects so the Google rankings follow, and payments and shipping have to be tested with real orders before the old shop closes. The reverse also holds: if you are happy on Shopify, a move is rarely worth the money.
Common questions
- What does a WooCommerce shop cost?
- A shop is a website with more moving parts, so the price goes up with the checkout, the product logic and every integration. I price the parts separately so you can see what the shop costs and what the plumbing costs, and you get the prices in writing before the work starts.
- Can you connect the shop to e-conomic or Billy?
- Yes, and it is usually the change that pays for itself fastest — an hour a week of retyping orders is a working week a year. An integration is priced on its own and includes error handling, retries and monitoring, so you hear about a failed sync before your bookkeeper does.
- Our shop is slow. Can that be fixed without rebuilding it?
- Usually, yes. Most slow WooCommerce shops are slow for ordinary reasons: too many plugins doing overlapping work, images served at desktop size to phones, and no caching in front of the pages that never change. I measure before and after so you can see what you paid for rather than take my word for it.
- Can you migrate us from Shopify or another platform?
- I can migrate the products, customers and orders, and I will be straight with you about whether the move is worth it. Leaving a hosted platform means you take on the hosting, the updates and the security yourself, or you pay someone to. Sometimes that is clearly right and sometimes it costs more than it gives back.
- How many orders a day can a WooCommerce shop handle?
- Far more than most shops asking the question are doing, once the caching and the database are right. WooCommerce gets blamed for scaling problems that are usually one unindexed query or a plugin running on every page load. Where a shop genuinely has outgrown it — thousands of orders a day, or a product catalogue with heavy variation logic — I will say so rather than sell you a year of tuning, and that conversation is better had from measurements than from opinion.
- Can you take over a shop from another agency?
- Yes, and it starts the same way any takeover does: access first, then an inventory of what is installed and what is actually being used. A technical review is the usual first step on a shop with real order volume, because an undiscovered fault in a shop can cost you a day of sales.
- Can our products show up in what the AI assistants answer?
- Some of them, and it comes down to the product data. The assistants read the product markup on the page — price, currency, stock status, delivery time, item number — and the shopping surfaces inside them also pull from a product feed. WooCommerce emits some of that markup itself, but it is often incomplete or contradicts what the page says, and a bot filter in front of the shop closes the whole question without anyone deciding to. I fix the markup, open access to the crawlers you want reading you, and set up a feed where it earns its place. That sits inside the technical SEO and GEO engagement.
- Do you work with Danish payment providers?
- Yes — the usual ones a Danish shop runs, including MobilePay through the standard gateways, card acquiring, and invoice payment for business customers. The part that takes the time is rarely the connection itself; it is the order states, the refunds and the partial captures behaving correctly when something goes wrong halfway through.
- Who owns the shop and the data if we stop working together?
- You do, throughout. The hosting, the domain, the payment gateway accounts and the shop database are yours and in your name, the code is standard WordPress and WooCommerce, and the integrations are documented well enough for another developer to pick up. A shop is a business asset, and moving it should not depend on my cooperation.
- Do you handle the marketing and the product copy?
- No. I do the technical half — speed, checkout, integrations and correctly configured tracking. For advertising, product copy and photography there are people better at it than me, and I am happy to say who.
Other stacks I work in
Not sure which one to pick?
Send a couple of lines about what you are trying to achieve. You get a reply within 24 hours, and an honest yes or no.