Build eCommerce Websites Blog

Building a support assistant that quotes your real policies

hello@w3nuts.co.uk (Samir Kaila) — Thu, 20 Aug 2026 00:00:00 GMT

Support assistants are the most requested automation on our AI enquiries and the one with the widest gap between a good build and a bad one. The difference is not model quality. It is whether the assistant is allowed to answer from what it knows, or restricted to answering from what you wrote.

The failure that makes this risky

Ask a general model what your returns policy is and it will tell you. Confidently, in your tone of voice, with a plausible number of days that came from the general shape of ecommerce rather than from your terms.

The customer has no way to tell the difference. They now believe they have thirty days because your website said so, and the conversation about whether your website really said so is one you will lose in every sense that matters.

Under the Consumer Protection from Unfair Trading Regulations, what a business tells a consumer about their rights matters. We are not lawyers and this is not legal advice — the engineering conclusion is simply that an invented answer is not a harmless bug, and the architecture has to make inventing impossible rather than unlikely.

Grounding, in plain terms

Grounding means the assistant does not answer from memory. It retrieves the relevant passage from your documents, and its reply is built from that passage or it does not reply at all.

The mechanism is unglamorous. Your policies, delivery terms, sizing guidance and FAQ answers are indexed. A customer question retrieves the closest passages. The model’s instruction is to answer using only those passages and to decline if they do not contain the answer.

Two details decide whether it works.

Quote rather than paraphrase where it counts. For anything with a number in it — a returns window, a delivery cost, a warranty term — the reply should carry your wording, not a summary of it. Paraphrase is where numbers drift.

Cite what it used. A reply that links the policy page it answered from lets the customer verify and lets you audit. It also makes wrong answers debuggable, because you can see which document it read.

Scope: what an assistant should and should not answer

Scope is a design decision, not a capability question, and it is where most of the risk is managed.

Question type	In scope?	Because
Returns, delivery, warranty terms	Yes	The source of truth is a document you control
Sizing and fit guidance you published	Yes	Same, provided the guidance actually exists
Stock availability	Yes	Read from the store, not from the model
Order status	Only authenticated	Personal data, and identity must be established first
Product specifications	Only from structured data	Prose descriptions are where invention happens
Whether a product suits a use case	Judgement call	Fine as opinion, dangerous as fact
Anything about a competitor	No	No source of truth, and nothing to gain
Discounts or exceptions	No	An assistant that can give a discount will give a discount

The last row is not hypothetical. An assistant with no rule against it will agree to a goodwill gesture if a customer pushes, because agreeing is what the conversation seems to want.

Order status deserves its own paragraph

Order status is the most requested capability and the one that turns a support widget into a data-protection question. The rule is simple and non-negotiable: no order information without authentication.

An assistant that will look up an order from an order number and an email address will do it for anyone who has both, and both appear in forwarded confirmation emails. Read the order from the order system after the customer has signed in, or do not offer the feature. ICO guidance for organisations is the place to start on what your obligations actually are.

The refusal path is the product

Most builds treat “I don’t know” as a failure state. It is the opposite: the refusal is what makes every other answer trustworthy.

A refusal that works has three parts. It says plainly that it cannot answer rather than producing something vague. It offers the handover immediately rather than after three more attempts. It carries the conversation to the person taking over, so the customer does not start again.

That last part is where assistants most often disappoint. A handover that drops context makes the customer explain twice, which is worse than not having offered help — and it is entirely a plumbing problem rather than an AI one.

What the logs are actually for

Every question the assistant declines is a gap in your documentation, written in a customer’s own words. That log is the most accurate content brief you will ever get.

In the deployments we have run, the decline log reliably contains the same handful of questions repeated dozens of times — questions the policy pages genuinely do not answer. Writing those answers improves the assistant, the policy pages, and the human support queue at the same time, and the assistant paid for itself by finding them.

Log the answered questions too, with the passage retrieved. When somebody eventually reports a wrong answer, the only way to fix it is to see what it read.

Testing it before customers do

Three test sets, and the second is the one people skip.

Questions it should answer. Fifty real questions from your support inbox, with the correct answers written down beforehand. Anything wrong is a retrieval problem, not a model problem.

Questions it should refuse. Legal advice, competitor comparisons, discount requests, anything about another customer’s order, and questions whose answer is not in any document. A pass here means refusing cleanly, not answering carefully.

Questions designed to break the rules. Polite persistence, hypotheticals, instructions embedded in the question, and requests to ignore previous instructions. The OWASP Top 10 for LLM applications is the useful reference for what to try, and prompt injection is the entry worth reading twice.

Re-run all three whenever the model, the prompt or the documents change. Behaviour drifts on model updates, and the only way to know is to test the same questions again.

Where automation genuinely helps here

Setting the risks out at length makes this sound discouraging, which is not the conclusion.

A grounded assistant answering delivery, returns and sizing questions removes a large share of a support queue’s volume, and it removes the most repetitive share. It answers at three in the morning. It is consistent, which humans under pressure are not. It never gets tired of the same question on its fortieth repetition.

Those are real gains, available today, at a scale that matters for a small team. They arrive on the condition that the assistant is restricted to what you actually wrote — which is a build decision made at the start, not a setting turned on later.

What we build, and what we decline to build

We build grounded assistants scoped to policy, delivery, returns and sizing, with an audited refusal path and a human handover that carries context. We instrument the decline log from day one because it is the most valuable output.

We decline to build assistants that answer from a general model without retrieval, that discuss orders without authentication, or that are permitted to negotiate. Those are not harder to build. They are easier, which is exactly the problem.

Category and search pages: the funnel nobody audits

hello@w3nuts.co.uk (Kay Patel) — Thu, 20 Aug 2026 00:00:00 GMT

Conversion work concentrates on two pages: the product page and the checkout. Between them sits the part of the store where a customer decides whether your catalogue contains what they came for, and it is audited about a tenth as often.

Why this part of the funnel gets skipped

Category and search pages fall between two owners. Design treats them as templates, merchandising treats them as a listing, and neither treats them as a conversion surface with its own failure modes.

The result is predictable. In the audits we run, stores can usually quote their checkout abandonment rate to a decimal place and cannot say what proportion of site searches return nothing at all. One of those numbers is being worked on. The other is often larger and entirely unexamined.

Search users are the audience you are ignoring

Customers who use site search have told you exactly what they want. In every store where we have compared the two groups, searchers convert at a higher rate than browsers — which is unsurprising, because a search is an intent statement, and it makes the neglect harder to justify.

Three failures account for most of the loss.

Matching only product titles. A customer searching “waterproof jacket” finds nothing when your products are named “Storm Shell II” and the word waterproof lives in the description. Indexing descriptions, attributes, category names and tags fixes this in an afternoon on most platforms.

No tolerance for how people type. Plurals, hyphens, misspellings and word order. “mens boots”, “men’s boots” and “boots mens” are one query to a customer and three to a naïve index.

Ranking by whatever the database returned. Results in database order are not results. Ranking should reflect availability, popularity and relevance, and a product that is out of stock should not be the first thing a searcher sees.

The zero-results page is the most expensive page you own

Nothing in a store wastes higher-intent traffic than an empty result set with no way forward. The visitor arrived, told you what they wanted, and received a blank grid.

A zero-results page that works does four things: states plainly that nothing matched, keeps the query visible so it can be corrected, offers the nearest alternatives under a looser rule, and provides a route to a person. That is a small amount of work protecting your most motivated visitors.

Worth saying explicitly: if a customer searches for something you genuinely do not sell, the honest answer is to say so rather than to present unrelated products. A shopper who is told plainly is more likely to come back than one who is shown a grid of things they did not ask for.

Filters: build from questions, not from your database

Most filter sets are assembled from whatever attributes the catalogue happens to hold. That is backwards. The right source is what customers ask about — the search log, the emails, the questions your support inbox answers repeatedly.

A useful test: for each filter, name the customer sentence it answers. “Filter by material” answers “does this come in leather?” and earns its place. “Filter by SKU prefix” answers nothing anybody has ever asked.

Every filter costs something. Vertical space on mobile, cognitive load on everyone, and a URL combination that may be crawled and indexed. Fewer filters that map to real questions beat a complete reflection of your product data.

Filters generate URLs. Four filters with five options each generate over six hundred combinations, most of which contain the same products in a different order, and a crawler will find them.

Google’s guidance on faceted navigation is the primary source worth reading before designing filters. The practical rules we apply:

Decide which filter combinations deserve to be indexable pages, and treat only those as real URLs
Keep everything else out of the index rather than hoping it will be ignored
Never let filtering create pages that differ only in sort order
Make the indexable ones genuinely useful — “waterproof walking boots” is a page worth having; “waterproof walking boots sorted by price descending” is not

Get this wrong and a store with two hundred products presents a crawler with fifty thousand near-identical pages. That is the same thin-content problem that a badly built location system creates, arriving through a different door.

Pagination that works for people and crawlers

Real paginated URLs, each linkable and each reachable without JavaScript. Products on page four should be findable by something that does not scroll.

Infinite scroll is not forbidden, but it should be layered on top of paginated URLs rather than replacing them — the pattern Google documents for incremental loading. Replacing pagination entirely breaks the back button, strands the footer permanently out of reach, and hides the deeper catalogue.

The audit we run, in order

Six checks, cheapest first. Most stores find something in the first two.

#	Check	What you are looking for
1	Search log, two weeks	Zero-result rate and no-click rate
2	Search five real product descriptions	Whether the index covers more than titles
3	Zero-results page	Query preserved, alternatives offered, route to a person
4	Every filter	The customer question each one answers
5	Filter URLs	How many combinations exist, and how many are indexable
6	Category page on a phone	How far you scroll before reaching a product

Check six catches the failure that surprises people most. On mobile, a category page carrying a banner, a description, a filter bar and a sort control can push the first product entirely below the fold, which means the page is doing everything except showing the catalogue.

Accessibility is not a separate pass

Filters and search are interactive controls, which makes them the part of a category page most likely to fail an accessibility check. Three things go wrong repeatedly and all three are covered by WCAG 2.2: filters implemented as clickable divs that a keyboard cannot reach, result counts that update without announcing anything to a screen reader, and a live region that announces every keystroke rather than the settled result.

Fixing them is not a favour to a minority of users. A filter that works with a keyboard also works with a phone in one hand on a train.

What we would change first

Given one week on a typical store, in this order: index descriptions and attributes as well as titles, then fix the zero-results page, then remove every filter nobody uses.

None of that is a redesign. All of it is cheaper than one, and in our experience it moves more revenue than the redesign it replaces — because the customers it helps had already decided to buy something.

Ecommerce Core Web Vitals: what actually moves the numbers

hello@w3nuts.co.uk (Kay Patel) — Thu, 20 Aug 2026 00:00:00 GMT

Core Web Vitals arrive in most stores as a red panel in Search Console and leave as a quote for a rebuild. Between those two events there is usually a week of work that would have fixed it, and the reason it does not happen is that nobody separates the three metrics from each other.

The three metrics, and what each one means on a store

Three numbers, each measuring a different kind of failure. The definitions are on web.dev; what follows is what each tends to mean when the site selling something is the one being measured.

Metric	Measures	Usual ecommerce culprit	Threshold
LCP	How long until the main content appears	The first image, unoptimised or discovered late	2.5s
INP	How long the page takes to respond to a tap	Third-party JavaScript from apps and tags	200ms
CLS	How much the layout jumps after drawing	Banners, badges and images without reserved space	0.1

Treating them as one score is the mistake that produces rebuild quotes. They have different causes, different fixes and different costs, and a store usually fails one of them rather than all three.

Field data is the only measurement that counts

Two kinds of measurement exist and only one of them is the thing being assessed.

Lab data is a single run on hardware you chose, on a connection you have, with your cache state. Lighthouse produces it. Its value is diagnostic: it tells you what is slow and why.

Field data is what real visitors actually experienced, gathered from Chrome and reported through the Chrome UX Report and Search Console. Its value is judicial: it decides whether you have a problem.

The two will disagree, sometimes dramatically, and the field data is the one that is right. A store whose lab score is 95 on a developer’s laptop and whose field LCP is four seconds has a four-second problem, because visitors are on mid-range phones on mobile networks, and a good number of them are on the other side of the world from the server.

Test the templates that carry traffic. Field data is grouped by URL pattern precisely because a homepage and a product page are different pages, and the homepage — the one everybody tests — is usually the fastest and least representative page in the store.

LCP: it is the image, and it is the first one

On stores, LCP is an image problem almost every time, and there are only three ways it goes wrong.

The image is too large. A 2400px hero delivered to a 390px phone is the most common single fault we find. Responsive sources and a modern format fix it, usually cutting the transferred bytes by most of their weight.

The image is discovered late. If the browser only learns about the hero after parsing CSS or running JavaScript, the download starts late no matter how small the file is. The fix is to make it discoverable in the initial HTML and, where warranted, to preload it.

The image is lazy-loaded when it should not be. Lazy loading is correct for everything below the fold and actively harmful for the LCP element, because it defers exactly the thing being measured. This is a one-attribute fix that we find on a surprising share of audits.

There is a fourth case, less common and more expensive: LCP is text, and the text is waiting for a web font. Font display strategy fixes that without a redesign.

INP: the apps are doing it

Interaction to Next Paint replaced First Input Delay because it measures every interaction rather than the first one, and it exposed something that stores had been getting away with: INP is dominated by third-party JavaScript.

On a typical store that means the app stack. A review widget, a chat launcher, two analytics tags, a personalisation script and a consent banner each want main-thread time, and a tap on the variant selector waits behind whichever one is busy.

The fixes, in order of how much they usually return:

Remove apps nobody uses. This is the largest and cheapest win available on most stores, and it is the one that gets deferred because removing things feels risky.
Load what remains after interaction becomes possible rather than during page load.
Move tags behind a consent gate that genuinely defers them until consent, which many implementations do not.
Break up your own long tasks last, because on most stores your code is not the problem.

We have measured stores where removing three unused apps moved INP more than a fortnight of code optimisation would have.

CLS: reserve the space

Cumulative Layout Shift is the cheapest of the three to fix and the most irritating to a customer, because it is what makes a tap land on the wrong thing.

Four causes account for nearly all of it: images without width and height attributes, banners injected above existing content, badges and star ratings arriving after the card has drawn, and web fonts swapping to a face with different metrics.

Every one is fixed by reserving space before the content arrives. Dimensions on images, a fixed height on the announcement bar, a placeholder the size of the review widget, and font metrics that match the fallback.

What to do first, and what it costs

Ordered by return against effort, which is not the order a rebuild quote suggests.

Order	Work	Typical effort	Moves
1	Audit and remove unused apps	A day	INP, LCP
2	Fix image sizing and formats	A day or two	LCP
3	Add dimensions and reserve space	Half a day	CLS
4	Correct lazy loading on the LCP element	An hour	LCP
5	Defer remaining third-party scripts	A day	INP
6	Theme or template work	Weeks	All three

Rows one to five are configuration and housekeeping on most platforms. Row six is a project. Quoting row six before trying rows one to five is how performance work gets a reputation for being expensive.

The honest case for doing this

Core Web Vitals are a real ranking signal and a modest one. A slow page about the right thing still beats a fast page about the wrong thing, and any agency implying otherwise is selling the wrong benefit.

The better argument is the customer. A visitor who taps a variant and sees nothing happen for half a second does not file a bug; they leave, and they were already interested enough to tap. That loss does not appear in any report — which is precisely why it goes unfixed for years.

Our stated position, offered as opinion: fix these because the store is unpleasant to use, and take the ranking effect as a bonus. Stores that chase the number tend to optimise the homepage, which is the page the least revenue depends on.

Measuring your own store this week

Three steps, no tooling to buy.

Read the field data. Search Console’s Core Web Vitals report, grouped by URL pattern. Note which template fails and which metric.

Reproduce it in the lab. Run Lighthouse on that template with mobile throttling — not on your desktop connection, which describes nobody.

Fix one thing and wait. Field data is a 28-day rolling window, so the report will not move tomorrow. Changing five things at once and watching one number is how teams end up unable to say what worked.

Shopify theme or custom build: how to decide

hello@w3nuts.co.uk (Kay Patel) — Thu, 20 Aug 2026 00:00:00 GMT

Most people asking this question have already decided they want a custom build and are looking for permission. The honest answer is that a premade theme is right more often than agencies say, and the deciding factor is not budget or ambition but how unusual your storefront genuinely is.

What the three options actually are

Three distinct routes exist and the middle one gets confused with both of its neighbours. A premade theme is bought and configured. A customised theme is a bought theme with development work on top. A custom theme is built from an empty starting point specifically for you. All three run in Shopify’s theme layer and all three keep the theme editor.

Headless is a fourth thing entirely, and it is a different conversation with different reasons.

The question that decides it

Count the things about how you sell that a normal storefront does not do. Not the things that feel special about your brand — every brand feels special — but mechanics a theme would have to be taught. A size chart is not unusual. A configurator that prices a made-to-order item from six dimensions is.

That count is the decision:

Genuinely unusual mechanics	Route	Why
None	Premade theme	You are paying to rebuild what already exists
One or two	Customised theme	Extend the theme at the two points it does not reach
Three or more	Custom build	You are now fighting the theme more often than using it
Any number, plus multi-brand or a bespoke interface	Consider headless	A theme is no longer the constraint being hit

The threshold is not a rule handed down from anywhere. It is where, in the builds we have run, the arithmetic flips: below it, customisation is cheaper; above it, the customisations start colliding with each other and a clean build costs less than the collisions.

When a premade theme is the right answer

A bought theme is the correct choice when your storefront works the way storefronts work: a catalogue, variants, a cart, a checkout, some content pages. That describes most first stores and a good number of established ones.

Buying one is not a compromise, and the reasons are practical. The responsive behaviour has been tested on devices you do not own. The accessibility basics are usually present. The theme’s developer fixes it when Shopify changes something underneath. You get to spend the money you did not spend on development on photography, which will do more for conversion than a bespoke grid.

The trap is buying a theme for a feature list. Themes advertise dozens of sections and layout options, and the ones that matter are the three you will actually use. A theme with fewer, better-built sections beats one with forty that each add weight to every page.

When customising is the right answer

Customisation earns its cost when a small number of specific things need to work differently and the rest of the storefront does not. A bought theme extended at two points is a normal, well-behaved store; a bought theme extended at fifteen is a maintenance problem wearing a theme’s name.

Work that customises well:

A product page section the theme does not offer, added as a proper Online Store 2.0 section so the editor can still move it
Bespoke filtering on a collection, where the catalogue has attributes shoppers actually filter by
A different variant selector, because yours has three axes and the theme assumed one
Removing what you do not use, which is the cheapest performance work available on a bought theme

Work that customises badly is anything that requires the theme to change its mind about page structure. Rewriting the cart, restructuring templates, or changing how the theme handles collections means you are now maintaining a fork of somebody else’s code without their release notes.

When a custom build is genuinely cheaper

A custom theme wins on total cost when the storefront is unusual enough that customisation becomes continuous. Three signals show up together in the projects where we have recommended it.

Every new requirement starts with “can the theme do”. When that sentence opens most conversations, the theme has stopped being a foundation and become an obstacle.

The customisations have started interacting. Two independent changes are fine. The sixth change breaking the third is the classic sign, and it gets worse rather than better.

Nobody can update the theme any more. A theme so heavily modified that applying its updates would destroy the work is, in practice, already a custom theme — just one with a worse history and no documentation.

At that point a clean build is not an indulgence. It is cheaper than continuing, and it produces something a second developer can read.

What a custom build actually costs to own

The build is the part everyone estimates. Ownership is the part that decides whether it was a good idea.

A custom theme is code that only you have. When Shopify deprecates something, nobody sends you a patch. When a browser changes behaviour, nobody has already fixed it. When the developer who built it moves on, the next person reads the code rather than the documentation of a widely-used theme.

None of that is an argument against custom builds. It is an argument for budgeting the second year, which most estimates do not. In our experience the projects that regret a custom build are not the ones that spent too much on it — they are the ones that spent everything on it and left nothing for the eighteen months afterwards.

What you should build custom regardless of route

Some things are worth building properly whichever route you take, because they are where money is won and lost.

The product page. Whatever the rest of the storefront is, the product page carries the conversion. It is worth custom work on a bought theme.

Anything unique to your sales process. A configurator, a bundle builder, an unusual quantity model — if that is why customers choose you, the theme should not be deciding how it behaves.

Performance. LCP on a theme is decided mostly by images and apps, not by the theme itself. Both are fixable on any route, and both are usually ignored on all three.

How we advise clients

Two questions, asked before any estimate.

First: what specifically can a theme not do for you? A concrete list of two or three mechanics means customise. A long list of aesthetic preferences means buy a theme and spend the difference on design work within it. An empty list means buy a theme, and the honest version of that advice sometimes costs us the project.

Second: who owns this in two years? A custom build is a long-term commitment to maintaining code. If the answer is “we would rather not think about that”, a well-chosen theme is the better business decision regardless of what the storefront could theoretically be.

Starting with a theme is not starting badly

The sequence most stores should follow is: buy a good theme, run it, find out what is actually limiting, then commission the specific work that removes those limits.

That order produces a brief written from evidence rather than from a wishlist. It also means the money spent on a custom build in year two is spent on things you know matter, rather than on your best guess in month one about how customers would behave.

We have rebuilt several stores where the second version was smaller than the first, because a year of running the first one showed which half of it nobody used.

Choosing WooCommerce hosting that actually works

hello@w3nuts.co.uk (Samir Kaila) — Thu, 20 Aug 2026 00:00:00 GMT

Hosting is where most WooCommerce performance problems begin and where almost none of them are diagnosed. The plan comparison tables that stores choose from measure disk space and bandwidth, neither of which has much to do with whether a checkout completes under load.

Why WooCommerce is harder to host than a website

A content site can be served almost entirely from cache. A store cannot. Cart contents, checkout, account pages and anything showing a logged-in customer’s data are generated per request, every request, because two visitors must never see each other’s basket.

That single constraint changes what good hosting means. Your homepage can be cached to within an inch of its life and it will not help the customer waiting on a checkout page. A store’s real capacity is its uncached request capacity, and that is what the plan comparison table never shows.

The four things worth asking about

Four questions separate hosting that will hold from hosting that will not. None of them appear on a pricing page.

Question	Why it decides the outcome	Bad answer
How many PHP workers, and what happens at the limit?	Each uncached request holds a worker; exhaustion queues customers	“Unlimited”
Is Redis object caching available?	Removes repeated database queries within a page load	“We have caching” without specifics
How is the database configured and where does it run?	Query latency dominates uncached response time	Shared database host, no detail
Who applies security patches, and how quickly?	Decides whether an unpatched service is your problem or theirs	Silence

Ask all four in one email. The quality of the reply tells you more than the specification does — a host that answers precisely has thought about stores, and a host that answers in adjectives has not.

PHP workers, and why “unlimited” is not an answer

A PHP worker handles one request at a time. A checkout that takes two seconds of server work occupies a worker for two seconds. Ten simultaneous checkouts on eight workers means two customers wait for a worker before their request starts.

Bandwidth is irrelevant to this and disk space is irrelevant to it. What matters is the arithmetic of workers against your slowest uncached request, which is why the useful question is not how many workers you get but what happens when they run out. Queuing is survivable. Errors at the checkout are not.

Reducing the time each request takes is usually cheaper than buying more workers, which is what the next two sections are about.

Object caching is the single biggest lever

WooCommerce asks the database a great many questions to render a page — product data, variations, prices, tax rules, cart contents, session state. Without object caching, the same query runs repeatedly within one page load.

Redis holds those results in memory for the duration, and enabling it is the largest single improvement available on most stores we audit. It is not a tuning detail; it is the difference between a store that feels quick and one that does not, on identical hardware.

Two things to check rather than assume: that Redis is actually connected rather than merely installed, and that it survives a deployment. We have found stores paying for object caching that had been silently disconnected for months.

The database is the part nobody looks at

Uncached response time is mostly database time. Three things matter and all three are invisible from the outside.

Where the database runs. On the same machine, latency is negligible. On a shared database host in another rack, every query pays a network round trip, hundreds of times per page.

Whether the tables are indexed for what WooCommerce actually asks. WordPress’s post-meta structure makes product queries expensive by nature; on large catalogues the indexes matter enormously, and on small ones they matter not at all.

How big the tables have got. Sessions, transients, order metadata and abandoned carts accumulate. A store that has never been cleaned down is answering every query against a table full of data from 2023.

Who patches what

Managed hosting and unmanaged hosting differ on one question that has nothing to do with performance: when a vulnerability is announced in PHP, the database, or the web server, who applies the fix?

On managed hosting, the host does, usually before you have read the announcement. On a VPS, you do, and if nobody has been given that job then nobody is doing it. Running your own supported PHP version is not optional — an unsupported one stops receiving security fixes entirely, and stores run on them for years without noticing.

This is the part of the decision that is not about money. A store on unmanaged hosting with no named administrator is carrying a risk it has not priced.

Staging is a hosting feature

WooCommerce updates need testing against real data, because the failures are rarely in the plugin and usually in the interaction between the plugin, your theme and your catalogue.

A staging environment that mirrors production — same PHP version, same database contents, same plugin set — turns an update from an act of faith into a fifteen-minute check. Hosting that offers one-click staging is worth more than hosting that offers more disk space, and it is the feature most often traded away to save a few pounds a month.

What we specify on client projects

Our default requirements, stated so a client can compare quotes on equal terms:

A supported PHP version, currently maintained rather than merely working
Redis object caching, connected and monitored
A database on the same machine or the same private network
Automated daily backups held off the server, with a tested restore
One-click staging that copies production data
Patching handled by the host, with a stated response time
HTTP/2 or HTTP/3, TLS, and a CDN for static assets

That list is deliberately unglamorous. None of it is a feature anybody boasts about, and all of it is what separates a store that stays up during a campaign from one that does not.

How to test a host before you commit

Two checks, both cheap.

Measure an uncached response. Load a cart or account page — never the homepage — and look at time to first byte. That number is the hosting, stripped of caching and images.

Ask what happens under load. Not “can you handle traffic”, which invites a yes, but “what happens when PHP workers are exhausted”. A host that describes queueing behaviour has thought about it. A host that says it will not happen has not.

Migrating without breaking things

Moving hosts is routine and the failures are predictable: DNS moved before the data finished copying, a database dumped while orders were still arriving, or a staging URL left in the database so live pages point at a hostname that no longer exists.

The safe sequence is to copy, verify, freeze orders briefly, re-sync, then move DNS with a short TTL set a day in advance. Store migrations differ from site migrations in one respect that matters more than any other: an order placed during the move must not be lost, which is why the freeze exists even though it is inconvenient.

Agency, freelancer or in-house: how to staff ecommerce work

hello@w3nuts.co.uk (Samir Kaila) — Wed, 19 Aug 2026 00:00:00 GMT

We are an agency, so treat this with appropriate suspicion. We have tried to write the version we would want to read if we were buying.

The three options, honestly

Freelancer

Best for: a defined task in one discipline with a clear end. A theme customisation, a plugin fix, a set of designs, a performance audit.

Strengths: cheapest per hour, often available within days, and you deal directly with the person doing the work. No account management layer, no overhead.

Weaknesses: one skillset. When they are ill, on holiday or busy with another client, work stops. Continuity depends entirely on one person’s availability and continued interest.

The hidden cost: coordination, once there is more than one. Two freelancers is manageable. Four means you are running a project — briefing each of them, resolving conflicts where their work meets, and holding the context nobody else holds. That management time is real and almost never budgeted.

In-house

Best for: one discipline needed full-time, long term, with enough work to keep that person genuinely occupied.

Strengths: deep context on your business that no external party accumulates. Immediately available. Cheaper over years than an equivalent retainer.

Weaknesses: four to twelve weeks to recruit and onboard before producing anything. One skillset again — and most stores need design, frontend, backend and integration work. Four employees to cover that costs considerably more than a retainer.

Single points of failure are absolute here. When your only developer leaves, your store development stops until you have hired again.

Agency

Best for: work spanning multiple disciplines, or work that must not stop.

Strengths: design, development and integration in one team. Continuity when someone is unavailable. Starts in a week or two. Scales up and down without recruitment or redundancy.

Weaknesses: more expensive per hour than a freelancer. Less embedded context than an employee. Quality varies enormously between agencies, and the good ones are not obvious from their websites.

The comparison

	Freelancer	In-house	Agency
Cost per hour	Lowest	Middle	Highest
Disciplines covered	One per person	One per person	Multiple
Time to start	Days	4–12 weeks	1–2 weeks
Continuity if unavailable	Work stops	Work stops	Team covers
Context on your business	Moderate	Deepest	Moderate
Management overhead	Yours	Yours	Included
Scales down	Stop booking	Redundancy	Pause or reduce
Minimum commitment	None	Employment contract	Varies
Best when	Defined single tasks	One discipline, long term	Continuous, multi-discipline

Two of those three columns win their own row. That is the point — this is not a table designed to make agencies look good.

When you should not hire us

Being specific, because vague qualification is not qualification.

Your project is a theme setup with light customisation. Hire a freelancer. You do not need us, and we will tell you so if you ask.

You need one developer full-time for the next three years and can recruit. Hire in-house. It is cheaper and they will know your business better than we will.

You need someone physically present for product photography, on-site systems testing, or workshops with a large stakeholder group. Hire locally for those parts, whatever you do about the rest.

Your real problem is traffic quality or product-market fit. No amount of development work will fix that, and spending a development budget on it is an expensive way to find out.

When an agency genuinely earns the difference

The work spans design, development and integration simultaneously
The store cannot stop improving because one person is unavailable
Volume varies month to month and you want to scale without recruiting
You want one accountable party rather than coordinating several
You need a discipline occasionally but not enough to employ it

That last point is underrated. Most stores need design work sometimes, backend work sometimes, and automation work occasionally. Employing all three is expensive; hiring three freelancers means managing three relationships.

A hybrid that works well

The arrangement we see succeed most often is one in-house person who knows the business deeply, plus external capacity for the disciplines they do not cover and the peaks they cannot absorb.

The employee owns context and continuity. The agency or freelancers supply breadth. Neither is asked to be something they are not.

How we structure it

Our answer for continuous work is ProNuts — a fixed monthly amount of capacity across design, frontend, backend and AI, with a dedicated project manager, published at a real price rather than “contact us”, and cancellable at any time.

For a single defined project with a clear end, we quote it as a project instead. A monthly retainer for finite work is worse value than a fixed quote, and recommending one would be selling you the wrong thing.

How to evaluate whichever you choose

The choice matters less than the quality of who you pick. These separate good from plausible.

Ask what they would not do. Anyone who says yes to everything is either inexperienced or telling you what you want to hear. A useful partner has opinions about what is a bad idea.

Ask about a project that went wrong. Not to catch them out — to see whether they can describe a failure honestly and what they changed afterwards. Everyone has one.

Ask who actually does the work. Particularly with agencies. If the people in the pitch are not the people on the project, that should be stated openly rather than discovered.

Ask how they hand over. What documentation exists at the end, who owns the code, and what happens if you leave. A reluctant answer here is informative.

Ask for a reference you choose, not one from a curated list.

Setting the arrangement up to work

Whichever you pick, the same things determine whether it goes well.

Written scope before work starts, however brief. Most disputes come from two parties holding different assumptions nobody wrote down.

One person on your side who owns the relationship. Work routed through three stakeholders with different priorities goes slowly and expensively.

Access sorted early. Hosting, platform, analytics, the systems being integrated. Waiting on credentials is the most avoidable delay there is.

Agreement on what “done” means for each piece of work, before it starts.

A regular short check-in rather than a long monthly one. Problems surface earlier and cost less.

None of that is specific to agencies, freelancers or employees. It is what makes any of the three work, and its absence is what makes all three fail.

The uncomfortable summary

Most businesses asking this question have already decided and are looking for confirmation. If that is you, the useful exercise is to argue the opposite case for ten minutes and see whether it holds.

If you are set on hiring, ask what happens to your store during the three months before they start and the two weeks a year they are on holiday. If you are set on an agency, ask whether one full-time person would cost less for the work you actually have. If you are set on freelancers, count how many hours a week you will spend coordinating them.

Any of the three can be the right answer. The wrong answer is the one chosen without asking those questions.

How to migrate ecommerce platforms without losing search traffic

hello@w3nuts.co.uk (Kay Patel) — Wed, 12 Aug 2026 00:00:00 GMT

Migrations lose traffic for one reason above all others: URLs that used to resolve stop resolving. Almost everything else is recoverable. That is not.

Export before you can’t

The first task, and the one with a deadline attached, because some of this data disappears with the old site.

Take these while the old site is still live:

Source	What it gives you	Recoverable later?
Search Console — Pages report	Every URL Google has, with impressions	Yes — history survives the site
Search Console — Queries report	Your ranking baseline	Yes
Live XML sitemap	URLs the platform believes exist	No
Full site crawl	Orphaned and unlinked URLs	No
Backlink report	Which URLs hold external links	Partially
Database export	Previously published, now unpublished URLs	No

The crawl finds what the other sources miss — old landing pages, paginated archives, attachment pages, campaign URLs. These are exactly the URLs nobody remembers and that quietly hold links.

Reconcile all sources into one list. That list is the specification for the redirect map, and every URL on it needs an answer.

Build the redirect map

Three possible outcomes per URL, and every URL gets one:

Preserved — same path on the new site, no redirect needed
Redirected — permanent redirect to the closest equivalent
Gone — deliberately returns 410, for genuinely retired content

Acceptance criterion: zero URLs unaccounted for. Not “the important ones”. All of them.

Rules that matter:

Redirect to the closest equivalent page, not to the home page. Bulk redirects to home are treated as soft 404s and pass nothing.
One hop. If the old site already had redirect chains, flatten them. Chains lose value and slow crawling.
Preserve where you can. Every URL that does not change is a URL that cannot break. On our own rebuild we kept /privacy-policy/ and /terms-conditions/ at their exact paths for this reason.
Watch the trailing slash. Decide a policy, apply it everywhere, and normalise the other form with a redirect.

What breaks on every migration

Two things, regardless of direction.

URL structure

Platforms enforce their own path conventions. Shopify requires /products/, /collections/ and /pages/ prefixes. Move to it and essentially every product and category URL changes.

This is not negotiable and it is not a bug. It simply means the redirect map is mandatory rather than optional, and any migration plan that treats it as a final-week task has the sequencing wrong.

Customer passwords

Password hashes are not portable. Every customer must reset.

You cannot engineer around this. What you can do is plan it:

Write the reset communication before launch
Schedule it to go out with the launch, not days later
Make sure support knows it is coming
Expect a spike in “I can’t log in” contacts regardless

Discovering this after launch, from tickets, is a genuinely bad first day for a new store.

Also plan for

Order history — migrate it if the platform allows, or keep the old system readable for returns and support
Reviews — often tied to product IDs that change; check the export path before committing
Transactional emails — every template needs rebuilding and testing on the new platform
Structured data — rebuild it, and validate before launch rather than after
Analytics — install and verify on staging, so you do not lose the first days of data
Third-party integrations — every system connected to the old store needs repointing

Test the redirects

A redirect map that has never been executed is a hypothesis.

On staging, run the full URL list and confirm each returns the expected status and lands on the intended page. Automate it — a script over a few hundred URLs takes minutes and catches the typos that a spot-check misses.

Check specifically for: chains, loops, redirects to 404s, and any URL that quietly falls through to the home page.

Launch and afterwards

Submit the new sitemap immediately. Keep the old sitemap available briefly so crawlers discover the redirects for URLs they already know.

Then monitor daily for two weeks:

404s in server logs, which is where you find URLs the map missed
Search Console coverage and crawl errors
Which redirects are actually being hit

Expect a dip. Search engines need to recrawl and reassess, and a few weeks of fluctuation is normal even on a clean migration.

The mistake that turns a dip into a problem is panicking into further changes mid-recovery. That restarts the reassessment from the beginning. Hold the line, fix genuine errors only, and let it settle.

If you skip the export

Sometimes a client decides a migration is really a fresh start and the old data is not worth capturing. That is a legitimate call for a small site, and it should be a decision rather than an oversight.

Be clear about the consequence: any indexed URL not in your map will 404, and you will have no baseline to measure recovery against. At minimum, take the Search Console export. It survives the site being switched off, it costs ten minutes, and it is the single most useful item on the list.

A realistic timeline

Migrations get compressed because the build feels finished. These are the stages that actually need time.

Weeks 1–2: inventory and mapping. Exports taken, URLs reconciled, redirect map drafted. This can run in parallel with the build and should start early, because it is the item most often left too late.

During the build: data preparation. Catalogue cleaning, which is nearly always needed and nearly always underestimated. Inconsistent units, missing attributes, duplicate products.

Week before launch: redirect testing. The full list, executed and verified on staging.

Launch day: sequence matters. DNS change, immediate smoke test of the critical paths, sitemap submission, then monitoring. Not a Friday afternoon.

Weeks 1–2 after: daily monitoring. 404 logs, coverage reports, and the checkout working. Fix genuine errors; resist restructuring.

Week 4 onwards: assess. Enough data has accumulated to tell recovery from a real problem.

What to tell stakeholders beforehand

The conversation that prevents a crisis three weeks after launch.

Traffic will dip. Say this before launch, in writing, with an expected shape and duration. A forecast that comes true is reassuring; the same dip unforecast looks like failure.

Rankings will move around before settling. Individual keyword positions during recovery are noise.

Some things will break. Not because the work was poor, but because no test environment reproduces real traffic on real devices. A defined fix window is normal.

The comparison point is month three, not week one.

Having that conversation early costs ten minutes. Not having it costs considerably more in confidence when the expected dip arrives and nobody was warned.

AI product descriptions that don't damage accuracy

hello@w3nuts.co.uk (Samir Kaila) — Wed, 05 Aug 2026 00:00:00 GMT

This is the automation we recommend starting with, for reasons covered in what to automate first: it pays back immediately and it fails safely, because mistakes are caught in review rather than by a customer.

It also fails badly when done carelessly, and the failure mode is worth understanding before you start.

The failure mode

A language model given a product name will produce a description. It will read well. It will be confident. And a portion of it will be invented, because the model has nothing factual to work from and generating plausible text is exactly what it does.

On a blog, an invented detail is an embarrassment. On an ecommerce site, it is a claim about a physical object that you then have to ship. “Water resistant to 50 metres” on a watch that is not, or “solid oak” on something veneered, is a consumer-protection problem before it is anything else.

The fix is not better prompting. It is better input.

Feed specifications, not names

Output quality tracks input quality almost linearly. Give the model:

Every factual attribute you hold — dimensions, weight, materials, compatibility, capacity
What is physically in the box
Care, washing or maintenance instructions
Any certifications or standards the product meets
The supplier’s technical sheet, if you have one

Plus three or four of your existing descriptions that represent the voice you want, so the model matches your register rather than inventing one.

If a fact is not in the input, it must not appear in the output. State that explicitly in the instruction, and check for it in review.

Build review into the workflow

Not “we’ll check them” — an actual step, with an actual owner, before anything publishes.

The economics survive this easily. Reviewing thirty drafts is far faster than writing thirty descriptions from scratch, so the time saving remains substantial even with a careful review pass.

What the reviewer checks:

Every factual claim traces to the input data. This is the whole point of the step.
No invented certifications, standards or awards.
Nothing about durability, safety or performance that you cannot support.
Voice matches the rest of the catalogue.
The description answers the questions the product page checklist requires, particularly what is included.

Where to start

Products with no description at all, or with a single line copied from a supplier feed.

Those pages have the most to gain and least to lose. Many stores have hundreds of them — long-tail products nobody had time to write copy for, which consequently convert poorly and rank for nothing.

Do not start by rewriting your best-performing products. That risks your strongest pages to fix something that is not broken, and it is a surprisingly common instinct.

On search rankings

Generated copy is not penalised for having been generated. Search engines assess whether content is helpful, original and accurate — not how it was produced.

What has always been a liability is thin, near-identical copy across many products. Generation tools make producing that failure much faster, which is the real risk. A hundred products with the same three paragraphs and a swapped product name is a duplication problem whether a person or a model wrote it.

The mitigation is the same as it has always been: each description should contain facts specific to that product. If the only difference between two descriptions is the name, one of them is not earning its page.

What not to generate

Safety claims, certifications, or regulatory statements. Ever.
Anything in a regulated category — supplements, medical devices, cosmetics claims — without qualified review.
Comparative claims about competitor products.
Reviews or testimonials. This should not need saying, and it does.

A realistic workflow

Export products missing descriptions, with all their attribute data
Generate drafts against a fixed instruction and style examples
Route drafts into a review queue, never straight to publish
Reviewer checks against the five points above
Approved copy publishes; rejected copy returns with a note on why
Track rejection reasons — patterns tell you what to fix in the instruction

That sixth step is what makes this improve over time instead of staying at a fixed quality level.

Measure it

Before starting, record how long writing one description takes and how many products lack one. Afterwards, track drafts produced, drafts rejected, and the rejection reasons.

If the rejection rate stays high, the input data is insufficient — not the model. That distinction saves a lot of wasted iteration on prompts.

Handling variants and near-identical products

The hardest case, and the one most likely to produce duplication.

A catalogue with forty variations of the same product — sizes, colours, capacities — cannot support forty genuinely distinct descriptions, and pretending otherwise produces exactly the thin near-duplicate content that causes problems.

The right structure is usually one product page with variants, not forty pages. Where the platform or the business genuinely needs separate pages, the description should focus on what differs, with shared information handled once as structured data rather than repeated as prose.

If you cannot articulate what makes two products different, that is a signal about the catalogue structure rather than a copywriting problem.

Keeping the house style consistent

Generated copy drifts toward a generic register unless anchored. Two things keep it consistent.

Style examples in the instruction. Three or four real descriptions you are happy with, provided every time. This does more than any amount of adjective instruction.

An explicit banned list. The words your brand does not use. Most brands have them, few write them down. Ours are in our own style guide and the same discipline applies to generated product copy.

Review the output periodically as a set rather than individually. Drift is invisible one description at a time and obvious across twenty.

A note on translation

The same principles apply, with one addition: a generated translation needs review by somebody who speaks the language and knows the product category.

Translation errors in product copy are not merely awkward. Sizing, materials, care instructions and safety information all carry real consequences when mistranslated, and the categories where translation is most commercially attractive are often the categories where errors matter most.

Who should own this

Not the person who set up the tool. The person who owns product content.

That distinction matters because the failure mode is editorial rather than technical. The workflow will keep producing drafts indefinitely; what determines whether the output is any good is whether somebody with judgement about your products is reading them before publication, and whether they are feeding rejection patterns back into the instruction.

In practice that is usually whoever writes product copy today. The automation does not replace them — it removes the blank page and leaves them editing, which is faster and generally more pleasant work.

Reducing cart abandonment: the changes that actually work

hello@w3nuts.co.uk (Kay Patel) — Wed, 29 Jul 2026 00:00:00 GMT

Cart abandonment advice is mostly a list of tactics with no ordering. This is the ordering, because the first item matters more than everything after it combined.

Show the delivered total before checkout begins

Unexpected extra cost is the most commonly cited abandonment reason in every study of the subject. Shipping, taxes and fees appearing at the final step, after the customer has invested time, is the single biggest leak in most stores.

It is also largely within your control:

Show delivery cost, or a clear estimate, on the product page
Show the full delivered total in the cart, before checkout begins
If a free-shipping threshold exists, show progress toward it
If costs genuinely cannot be known before an address is entered, say so explicitly rather than leaving a blank

The goal is that nothing at the final step is a surprise. A customer who knows the total and proceeds anyway has already accepted it.

Make guest checkout the obvious option

Forcing account creation sits near the top of every abandonment study, and the accounts you gain that way are largely worthless — created under duress, never used again.

Offer guest checkout prominently. Not hidden below a login form, not styled as the lesser option. Then invite account creation after the order is placed, when the customer has an actual reason to say yes: order tracking, faster reordering, saved addresses.

Remove every field you do not use

Audit what you collect against what anybody actually uses.

The usual suspects: company name on a consumer store, second address lines, phone numbers nobody calls, “how did you hear about us” on the checkout form rather than after it.

Each removed field is a small increase in completion, and they compound. This is one of the cheapest changes available and it is skipped because nobody owns the form.

Fix the error handling

Error handling is where checkouts lose people who had every intention of buying.

Show errors inline, beside the field, not as a summary at the top
Say what to do, not that something is invalid: “Enter an email address so we can send your receipt” beats “Invalid input”
Validate as the customer moves through the form, not only on submit
Never clear entered data when an error occurs — that is the fastest way to lose someone entirely
Move focus to the first field with a problem

That last point is both a usability improvement and an accessibility requirement.

Show payment methods early

Customers who intend to pay with a specific method want to know it is available before investing effort. Show accepted cards, digital wallets and any buy-now-pay-later options in the cart, not at the final step.

If you offer a wallet that skips most of the form, put it at the top of checkout where it can be chosen before someone starts typing.

Make it work properly on a phone

Most abandonment happens on mobile, and a substantial share is mechanical rather than motivational:

Correct input types, so numeric keyboards appear for numeric fields
autocomplete attributes so saved details fill in
Targets large enough to hit accurately
Forms usable one-handed
No layout shift as the page settles

None of this is glamorous. All of it is measurable.

Do not oversell recovery emails

Abandoned-cart emails work, within limits. They recover some orders, and they are worth having.

They are not a substitute for fixing why people left. A recovery email for a customer who abandoned over unexpected shipping cost is asking them to accept the thing they already rejected. Fix the cause, then let the email catch genuine distractions.

Accept that some abandonment is healthy

A meaningful share of carts are not purchase attempts at all. Customers use carts as wishlists, as price comparison tools, and as a way to check delivery cost before deciding.

Published abandonment figures around seventy percent include all of that. Track your own trend rather than benchmarking against an industry average, because the composition of your traffic determines what “normal” means for you far more than the sector does.

Measure it properly

Before changing anything, record checkout completion rate and the step where people leave. Afterwards, compare the same two numbers over a full traffic cycle.

Checkout is one of the few places on most stores with enough volume for genuine A/B testing. If you are going to test anything rigorously, test here. Elsewhere, as covered in the product page checklist, most stores lack the traffic for meaningful results.

Where to start if you can only do three things

In order:

Put delivery cost and estimated arrival on the product page, not only at checkout. This is the highest-value change available on most stores and it is a content change rather than a development one.
Make guest checkout obvious. Not present-but-hidden. Obvious.
Remove every checkout field nobody uses. Audit against what your fulfilment process actually needs.

None of those requires a redesign, and together they address the top three reasons cited in essentially every abandonment study.

Diagnosing your own funnel

Before applying any of this, find out where your customers actually leave. The pattern differs by store and the fix differs with it.

High cart abandonment, low checkout abandonment — people are adding to cart and never starting checkout. Usually a pricing or delivery-cost surprise at the cart step, or carts being used as wishlists.

Low cart abandonment, high checkout abandonment — people commit and then stall. Look at form length, required fields, payment method availability and error handling.

Abandonment concentrated on mobile — check the mechanical things first. Input types, autocomplete, target sizes, layout shift. Motivation is rarely the issue when desktop converts fine.

Abandonment concentrated at the payment step — a payment method customers expect is missing, or the step is failing for some cards and nobody has noticed. Check your error logs rather than guessing.

That last case is worth emphasising. Genuine checkout errors are more common than people assume, and they are invisible from the outside because the affected customers simply leave. Reading payment failure logs occasionally is unglamorous and occasionally alarming.

What good looks like

A checkout worth having:

The delivered total is known before checkout begins
Guest checkout is the obvious default
Every field present is a field that gets used
Errors appear beside the field, in plain language, without clearing entered data
Payment methods are visible early, and wallets sit at the top
It works one-handed on a phone with saved details filling in
Somebody reads the payment failure logs occasionally

None of that is novel and most stores fail at least three of them.

One more thing

Check that your checkout actually works, on a real phone, on a real network, this week. Not a staging copy — the live one, with a real card, refunded afterwards.

We have found genuinely broken checkouts on stores whose owners had no idea, because the affected customers simply left and nobody reports a checkout that quietly fails.

Custom WooCommerce plugins vs stacking third-party ones

hello@w3nuts.co.uk (Samir Kaila) — Wed, 22 Jul 2026 00:00:00 GMT

WooCommerce’s plugin ecosystem is genuinely one of its strengths. It is also the most common route by which a maintainable store becomes an unmaintainable one.

The test we apply

Before installing any plugin on a client store, we ask one question:

Would fifty lines of custom code do this?

If yes, we write the fifty lines. Not because writing code is inherently better, but because fifty lines we wrote can be read, understood, tested, and removed. A plugin cannot always be any of those things.

That is the whole heuristic. Everything below is elaboration.

What a plugin actually is

A plugin is code written by somebody else, running inside your store, with full database access and the ability to modify almost anything.

Most of the time that is fine — the ecosystem contains excellent, well-maintained work. But it is worth being clear about what installing one means, because “just install a plugin” is said far too casually.

When a third-party plugin is the right answer

Install one when the problem is common, well-defined, and solved better than you would solve it.

Good candidates:

Payment gateway integrations, which need PCI knowledge and ongoing certification work
Subscription billing, where dunning and failed-payment recovery are genuinely hard
Established shipping carrier integrations
Security and backup tooling
Anything requiring a maintained relationship with an external API

The common thread: these are problems where somebody else’s specialised, continuously-maintained work is genuinely better than yours would be. Writing your own payment gateway would be a poor use of anyone’s budget.

When custom is the right answer

Write your own when the requirement is specific to your business.

Good candidates:

Pricing rules unique to how you trade
Order routing based on your own operational logic
Integrations with systems you use that have no existing plugin
Any requirement where the nearest plugin does 70% of it and you would have to bend your process to fit
Anything where you would otherwise install three plugins that each do part of it

That last one matters most. Three overlapping plugins is worse than one custom plugin, because nobody can then say which one owns a given behaviour when it misbehaves.

Where custom code belongs

In a versioned plugin. Not in the theme’s functions.php.

This is not a stylistic preference. Code in functions.php dies with the theme — change or update the theme and your business logic vanishes with it. Code in a plugin survives theme changes, can be code-reviewed properly, deployed independently, and rolled back on its own.

It costs nothing extra to do it correctly and it saves an entire category of incident. We have inherited stores where critical pricing logic lived in a child theme nobody had documented, discovered only when the theme was updated.

Evaluating a plugin before installing

If a third-party plugin is the right call, check:

When was it last updated? Six months is fine. Two years is a warning.
Does the developer answer support threads? An unanswered forum is the clearest signal available, and a better indicator than install count.
Is it compatible with your WooCommerce and PHP versions? Explicitly stated, not assumed.
What does it load on the front end? Some plugins add scripts sitewide for admin-only functionality.
What happens if it disappears? If the developer stops maintaining it, how hard is it to replace or remove?

That fifth question is the one nobody asks, and it is the one that matters in three years.

The accumulation problem

The failure we see most often is not one bad plugin. It is forty plugins where:

Three do broadly the same job
Two were abandoned by their authors years ago
Several were installed for something that ended
Nobody can say which one owns the checkout behaviour that is misbehaving

None of those plugins was a bad decision individually. The set is a bad outcome collectively, and it happened because each addition was evaluated alone.

Review the whole list periodically, not each addition in isolation.

A practical policy

Ask whether fifty lines would do it
If installing, evaluate against the five questions above
Put custom logic in a versioned plugin, never the theme
Delete rather than deactivate
Review the full plugin list quarterly and remove what is unused
Document what each remaining plugin is for, so the next person knows

Unglamorous, and the difference between a store that is still maintainable in five years and one that is rebuilt in three.

What a well-built custom plugin looks like

If you are commissioning one, these are reasonable expectations.

It is a plugin, with a proper header, activation and deactivation hooks, and an uninstall routine that cleans up after itself. Code that leaves database rows behind on uninstall is part of the accumulation problem, not a solution to it.

It does one thing. A single plugin containing pricing logic, an integration and three unrelated tweaks is harder to reason about and impossible to remove selectively.

It follows WordPress coding standards, so any competent WordPress developer can pick it up. Bespoke code written in a house style nobody else recognises is a lock-in of a different kind.

It is version controlled and deployed, not edited on production through the file manager.

It is documented, at minimum a README explaining what it does, why it exists, and what depends on it. Six months later this is the difference between a five-minute change and an afternoon of reading code.

It handles failure. External API down, unexpected data, missing configuration — it should degrade rather than break the store.

Auditing what you already have

For an existing store where nobody is sure what is running:

Export the plugin list with versions, last-update dates and active status.
Flag anything not updated in over a year. Check whether the developer is still active.
Identify overlaps. Group plugins by what they do; anywhere two appear in the same group, one is probably removable.
Find the custom code. Check the theme’s functions.php, any child theme, and any plugin with a name matching your business rather than a vendor.
Test removals on staging, one at a time, with a way back.
Document what survives and why.

That process typically removes a third of the list on a store that has been running for a few years, and it makes everything after it easier — updates, debugging, and onboarding whoever maintains it next.

The short version

Ask whether fifty lines would do it. Put anything bespoke in a versioned plugin rather than the theme. Check the last update date and the support forum before installing anything. Delete what you are not using rather than deactivating it. Review the whole list quarterly rather than evaluating each addition alone.

Six rules, and following them is most of the difference between a WooCommerce store that stays maintainable and one that gets rebuilt.

Why your WooCommerce store is slow, and how to fix it

hello@w3nuts.co.uk (Kay Patel) — Wed, 15 Jul 2026 00:00:00 GMT

Almost every slow WooCommerce store we have taken over was slow for a configuration reason, not a code reason. That is good news: configuration is cheaper to fix than architecture.

Work through these in order. Do not skip to the interesting ones.

1. Is there a persistent object cache?

Check this first. It is the most common cause by a wide margin.

WordPress makes a large number of repeated database queries per request. Without a persistent object cache, every one of them hits the database, every time, for every visitor.

With Redis or Memcached, repeated query results are held in memory. On the stores we have inherited, enabling this has routinely done more for admin and cart response times than any amount of frontend work.

Most hosting plans do not enable it by default. Many store owners have never been told it exists.

How to check: look for a persistent object cache in your site health information, or ask your host directly whether Redis or Memcached is available and active. “We have caching” usually means page caching, which is a different thing.

2. How many plugins are active, and what do they do?

Each active plugin runs code on requests, and some run code on every request whether or not it is needed.

The specific things to look for:

Plugins doing work on the front end that only relate to admin functions
Two or more plugins solving broadly the same problem
Plugins abandoned by their developers
Anything installed for a campaign or experiment that ended

Deactivating is not enough — delete what you are not using. Deactivated code still sits on disk and still represents a security surface.

3. Is page caching configured correctly?

Page caching serves a static copy of a page rather than generating it per request. It is enormously effective on catalogue and content pages.

It must never cache cart, checkout or account pages. If it does, customers see one another’s carts and totals. The resulting bugs appear random and intermittent, which makes them expensive to diagnose unless somebody suspects the cache.

Correct exclusions are the difference between page caching being a large win and being an incident.

4. Is the store still on legacy order storage?

WooCommerce historically stored orders in the WordPress posts table, alongside pages and blog posts. That works until order volume grows, at which point order queries compete with content queries for the same indexes.

High-Performance Order Storage moves orders into purpose-built tables. If your store predates it and has never migrated, admin and reporting are doing far more work than they need to.

Migrating is a configuration change with a synchronisation step, not a rebuild. On a store with meaningful order history the difference in admin responsiveness is immediate.

5. Are the images doing damage?

Common and easily fixed:

Originals uploaded at full camera resolution and scaled down in the browser
No modern formats served
No explicit width and height, causing layout shift as they load
Every image loading eagerly, including those far below the fold

Product galleries are usually the worst offender, because they contain the most images on the most commercially important template.

6. Is the database carrying dead weight?

Over years, a WooCommerce database accumulates:

Expired transients that were never cleaned up
Post revisions, sometimes hundreds per page
Orphaned metadata from plugins removed long ago
Autoloaded options — settings loaded into memory on every request

That last one deserves attention because it is invisible. Plugins add autoloaded options freely and rarely clean up on uninstall. The table grows quietly for years, and every page view carries the weight.

Checking the size of your autoloaded options is quick, and trimming it is one of the safest wins available.

7. Is the hosting adequate at all?

If the first six are addressed and the store is still slow, the infrastructure may simply be undersized: insufficient PHP memory, an outdated PHP version, a database server shared with too many neighbours, or no CDN in front of static assets.

At that point the fix is a hosting move, not more optimisation. Specification detail is in running WooCommerce properly.

Measure admin and front end separately

They have different causes and different fixes.

A fast storefront with a slow admin points at the database, legacy order storage, or plugins doing heavy work on admin screens. Page caching hides frontend problems from you while doing nothing for the people actually running the store.

If your team complains the site is slow and your monitoring says it is fast, this is usually why.

What this costs

Most of the above is configuration and hosting rather than development. That means the fix is normally faster and cheaper than the rebuild people often assume they need.

We audit before quoting performance work, because quoting a rebuild for a store that needs an object cache switched on would be charging for the wrong job.

A diagnostic session, in order

If you are working through this yourself, this is the sequence that finds problems fastest.

Measure first, on a real page. A product page and a category page, on mobile, throttled. Note Largest Contentful Paint, total transferred bytes and main-thread time. Without a baseline you cannot tell whether anything you do helps.

Check the object cache. One question to your host. Five minutes.

Count and identify plugins. How many are active, and can somebody name what each does?

Check the PHP version and memory limit. Both are visible in site health.

Check order storage mode. Legacy or High-Performance Order Storage.

Look at the autoloaded options total. Anything unusually large points at plugin residue.

Test the admin separately. Load an order list and a product edit screen. If these are slow while the front end is fast, page caching is hiding a database problem.

Only then look at the theme and images. They matter, and they are rarely the largest contributor.

That order is deliberate: it goes from cheapest-to-check and highest-impact toward most-effort and lowest-impact. Working the other way round is how people spend a week optimising images on a store with no object cache.

When it is genuinely a code problem

Sometimes the configuration is right and the store is still slow. The usual culprits:

A plugin running expensive queries on every page load, often something that should only run on a single template
Custom code in the theme doing database work inside a loop
An external API called synchronously during page render, so the store is as slow as somebody else’s server
Missing database indexes on custom tables added by a plugin

These need profiling to find rather than guessing. But they are the minority, and checking them before the configuration items above wastes the expensive diagnostic effort on the least likely cause.

Keeping it fast

Performance is not a one-off project. Stores slow down again, predictably, as plugins are added and the database grows.

Re-run the diagnostic sequence twice a year, and always before a peak trading period. It takes an hour once you have done it once, and it catches degradation while it is still cheap to reverse.

The Shopify apps quietly slowing your store down

hello@w3nuts.co.uk (Samir Kaila) — Wed, 08 Jul 2026 00:00:00 GMT

When a store is slow, the instinct is to optimise the theme. On Shopify that is usually the wrong place to start, because the theme is rarely the biggest contributor.

The mechanism

Most apps add frontend functionality by injecting JavaScript. That script is added to your theme, and it loads on every page — not only on the pages where the app is actually used.

A review widget needed on product pages loads on your home page. An upsell tool needed at cart loads on your privacy policy. A currency converter loads on your blog. Each is small. Twenty of them are not, and they all compete for the same single main thread that also has to respond when a customer taps a variant selector.

This is why two stores on the same theme can differ enormously in speed.

Audit before you optimise

Doing theme work on a store carrying twenty apps is treating the symptom. The audit comes first, and it is straightforward.

Step 1 — List every app, and what it does

For each installed app, write down:

What problem it solves
When it was last actually used or configured
Whether the platform has since built the feature in
Whether another installed app does something similar

That fourth question finds the most. Stores routinely run two apps that both do product recommendations, or three that all touch the cart.

Step 2 — Establish what each one costs

Measure the store with the app active, then in a duplicate theme with it removed. What you are looking for is the change in total JavaScript, in main-thread work, and in interaction responsiveness.

Some apps cost almost nothing. Others are startling. You cannot tell which is which by reading the app listing.

Step 3 — Decide, honestly

For each app: does the revenue or time it produces exceed what it costs in subscription and in speed?

For a genuinely effective upsell tool, often yes. For a currency converter on a single-market store, or a popup nobody has updated in a year, almost never.

Step 4 — Check what uninstalling leaves behind

This is the step everyone skips.

Apps built as theme app extensions remove cleanly. Apps that injected script tags or edited theme files often leave fragments behind. Those fragments then load forever, doing nothing, for an app you no longer pay for.

After uninstalling, search the theme for the app’s name and any script domains it used. We have found remnants of apps removed years earlier still loading on every page view.

What to look for specifically

Categories that most often cost more than they return:

Popup and email capture tools — frequently load a large bundle for a modal
Review widgets — value varies enormously by implementation
Currency and geolocation switchers — Shopify Markets handles much of this natively now
Multiple analytics tools — each adds a script, and most stores use one properly and ignore two
Anything installed for a campaign that ended

That last category is the most common and the easiest to remove.

What to do with what remains

Once the list is genuinely necessary:

Prefer apps built as theme app extensions. Scoped loading, clean removal.
Ask whether metafields would do it. A great deal of what stores install apps for is structured product data, which Shopify handles natively at no monthly cost. See the custom Shopify build guide.
Ask whether Shopify Functions would do it. Discount and shipping logic runs natively rather than through an app.
Load what remains as late as possible, and never let a third-party script block first render.

Then optimise the theme

With the app list honest, theme work becomes worth doing: image sizing and formats, above-the-fold render order, removing unused CSS, deferring non-critical scripts.

That work matters. It is simply not where the biggest win is on most stores, and doing it first means fixing the small problem while the large one keeps growing.

Review it on a schedule

Apps accumulate the way subscriptions do — one at a time, each justified individually, never reviewed as a set. Audit at launch and every six months afterwards.

It is usually the fastest performance win available, and it saves money at the same time, which is a rare combination.

Building the habit

An app audit is not a one-off task. Apps accumulate the way subscriptions do, and the only defence is a routine.

At launch. Every app justified, documented, and its performance cost measured. Write down what each does, so the next person is not guessing.

Every six months. Full audit against the four steps above. Half a day, and it reliably finds both money and speed.

Before every peak trading period. The worst time to discover an app is slowing checkout is during your busiest week. A shorter check — measure, compare against last time, remove anything obviously unused — takes an hour.

Whenever somebody wants to install one. A single question at the point of installation: what problem does this solve, and what happens to it when that problem passes? Most unnecessary apps are installed to solve a temporary problem and never revisited.

What to measure

If you want numbers rather than impressions, measure these before and after each change:

Total JavaScript transferred on a product page and on the home page
Main-thread work, which is where app scripts actually cost you
Interaction responsiveness, because variant selection and cart interactions happen after load
Largest Contentful Paint, on mobile, throttled

Test on a duplicate theme rather than live, and test the same page each time so comparisons mean something.

The reason to measure rather than assume is that app cost varies enormously and unpredictably. A visually simple app can ship a large bundle; a complex-looking one can be well built and nearly free. You cannot tell from the listing, and you cannot tell from the price.

The wider point

Every app is a decision to accept somebody else’s code, running on every page, in exchange for a feature.

Frequently that is a good trade — the ecosystem contains genuinely excellent work, and building the same functionality yourself would cost far more. The problem is not any individual trade. It is that the trades accumulate, nobody reviews the total, and a store ends up carrying twenty of them when it actively uses six.

A short version

If you remember one thing: audit before you optimise. Doing theme work on a store carrying twenty apps is fixing the small problem while the large one keeps growing, and it is how performance budgets get spent for very little return.

Before you start

Take a measurement of your product page today, on mobile, throttled, and write the numbers down. Everything in this article is easier to act on when you can see whether it worked, and impossible to justify afterwards when you cannot.

Do you need Shopify Plus? The honest threshold

hello@w3nuts.co.uk (Kay Patel) — Wed, 01 Jul 2026 00:00:00 GMT

Shopify Plus is usually sold on revenue thresholds. That framing is convenient for a sales conversation and unhelpful for a technical decision, because the thing you are actually buying has nothing to do with turnover.

What you are actually buying

Checkout control. That is the honest answer.

Below Plus, Shopify’s checkout is closed. You can style it — colours, logo, some layout. You cannot change its logic. There is no way to add custom validation, conditional fields, bespoke steps, or business rules Shopify has not anticipated.

This is a deliberate platform decision and it is why Shopify’s checkout converts as well as it does. It is also an absolute ceiling if your business needs something the standard flow does not offer.

The questions that actually decide it

1. Do you need to change checkout logic?

Specifically, do you need any of these?

Custom validation before an order can be placed
Conditional fields based on cart contents or customer type
Approval or purchase-order workflows
Minimum order quantities enforced at checkout
Bespoke tax or shipping logic beyond the built-in rules
Age, licence or eligibility verification as a checkout step

One yes means Plus, if you are staying on Shopify. There is no workaround, and attempting one through apps produces a fragile arrangement that breaks on platform updates.

2. Do you sell to businesses on account terms?

Shopify’s B2B features — company accounts, multiple buyers per company, customer-specific catalogues and price lists, payment terms — are Plus-only.

Below Plus you can approximate wholesale through apps or a second storefront, but you end up maintaining parallel catalogues or accepting that trade customers check out like retail ones. If wholesale is a meaningful revenue share, that compromise costs more in operational friction than the plan difference.

3. Do your integrations hit API rate limits?

Plus raises them substantially. This matters for stores with heavy ERP synchronisation or high order throughput, and for almost nobody else. If you do not currently see rate-limit errors, this is not your reason.

4. Do you need multiple storefronts under one organisation?

Multiple markets with genuinely separate catalogues, or multiple brands, are easier to administer on Plus. Note that multi-currency and multi-region selling alone do not require Plus — Shopify Markets handles that on standard plans, and this is a common misunderstanding.

Reasons that are not reasons

Being candid about the ones we hear:

“We’ve hit the revenue threshold.” There is no technical threshold. If nothing above applies, the plan buys you nothing you will use.
“We want better support.” Real, but rarely worth the difference alone.
“We want to look established.” Nobody outside your business can tell which plan you are on.
“We need better performance.” Plus does not make your storefront faster. Your theme, your apps and your images do that.

If you are on Plus and cannot name which Plus-only feature you use, you are paying for a badge. That is worth checking — we have found it more than once during audits.

A note for existing Plus customers

Shopify replaced the old checkout.liquid customisation approach with Checkout Extensibility. If your Plus checkout was customised before that transition, those customisations need rebuilding as extensions.

This is not optional maintenance and it is not a small job on a heavily customised checkout. If nobody has raised it with you, raise it with whoever maintains your store.

What to do instead, if the answer is no

If none of the four questions applies, stay on a standard plan and put the difference into things that actually move revenue:

Product photography, which is chronically underinvested in
Fixing the information gaps on your product pages
Auditing the apps slowing your store down
Content that brings qualified traffic

Any of those will do more for a typical store than a plan upgrade nobody outside the business will notice.

What Plus does not fix

Worth naming, because these come up in the sales conversation and none of them is a Plus feature.

Performance. Plus does not make your storefront faster. Your theme, your apps and your images determine that, on any plan.

Conversion. The checkout is the same checkout below Plus unless you change it, and changing it is as likely to hurt as help without measurement.

Search rankings. No plan tier affects how you rank.

App costs. You still pay for apps, and Plus-tier pricing on some apps is higher.

A poorly structured catalogue. Plus gives you more control over checkout, not better product data.

If any of those is your actual problem, the plan upgrade is an expensive way to not solve it.

How the decision usually goes wrong

Two patterns we see repeatedly.

Upgrading too early, because revenue crossed a threshold somebody mentioned. The business pays materially more for features it does not use, and the money would have done more as photography, content or development.

Upgrading too late, having spent eighteen months and considerable development budget engineering around a checkout limitation that Plus would have removed. This one is more expensive, because the workaround usually has to be unpicked afterwards.

The way to avoid both is to answer the checkout question honestly at the start of a project rather than at the point of frustration. If the requirement exists, it exists now — it does not appear later.

If you are already on Plus and unsure

Three questions:

Which Plus-only feature are you actually using? Name it specifically. Not “the support” — a feature.
When did you last review the checkout customisations? If they predate Checkout Extensibility, they need rebuilding.
Is the B2B functionality genuinely in use, or was it set up and abandoned?

If the answers are vague, it is worth modelling what a standard plan would cost you and what you would lose. Sometimes the answer is that Plus is well justified. Sometimes it is a legacy decision nobody has revisited.

A summary you can act on

Work through this in order and stop at the first yes:

Do you need to change checkout logic? Yes → Plus.
Do you sell B2B on account terms, at meaningful volume? Yes → Plus.
Are your integrations hitting API rate limits today? Yes → Plus is worth costing.
Do you run multiple genuinely separate storefronts? Yes → Plus is easier.
None of the above? Stay on a standard plan.

If you reached five, the money is better spent on photography, product content, or fixing the information gaps on your product pages. None of those are as satisfying to buy as a plan upgrade, and all of them will do more for revenue.

Why this article exists

Because we have watched businesses upgrade for reasons that do not survive examination, and watched others spend eighteen months and a great deal of development budget engineering around a limitation that Plus removes in an afternoon.

Both are expensive, and both come from the same cause: the plan decision being framed around revenue rather than around what the checkout needs to do. Ask the checkout question at the start of a project and the answer is usually obvious.

When headless commerce is worth it — and when it isn't

hello@w3nuts.co.uk (Samir Kaila) — Wed, 24 Jun 2026 00:00:00 GMT

Headless is the most requested architecture we talk clients out of. Not because it is bad — it is genuinely excellent for certain situations — but because the reason people ask for it is usually solvable more cheaply.

What headless actually is

Your storefront becomes a separate application. It fetches products, collections and cart state from the commerce platform through an API, and you build and host the frontend yourself. The platform continues handling catalogue, payments, orders and fulfilment behind it.

You gain complete control over the frontend. You take on responsibility for building and running it.

What you give up

This half gets discussed less than it should.

The theme editor. Your marketing team can no longer drag a section, change a banner or reorder a page. Every visual change becomes a development ticket with a deployment behind it.

For teams accustomed to making their own changes, this is a bigger day-to-day shift than the build cost. It is also the thing most often glossed over during the decision.

Most of the app ecosystem’s frontend. Apps that add storefront functionality generally do it by injecting into a theme. Without a theme, they have nowhere to inject. Some offer headless-compatible components; many do not. Every app you rely on for frontend behaviour needs checking before committing.

Simplicity. You now have two systems, two deployment pipelines, and a hosting bill for the storefront.

What you gain

A higher performance ceiling. You control every byte. Nothing loads that you did not choose. Done well, headless storefronts are extremely fast.

Note the phrasing. The ceiling is higher; the floor is lower. A headless storefront shipping a large JavaScript bundle for a product page is slower than a well-optimised theme. The architecture creates an opportunity, not a guarantee, and we have audited headless builds that were slower than the theme they replaced.

Complete design freedom. No theme constraints, no fighting someone else’s assumptions.

One backend, many frontends. Several brands or storefronts sharing a catalogue and order pipeline is genuinely much easier headless.

Deep content integration. If commerce and editorial content need to interleave properly — shoppable articles, content-led navigation, campaign microsites sharing the cart — headless removes a lot of friction.

Good reasons to go headless

Multiple storefronts on one commerce backend, particularly multi-brand
Editorial and commerce genuinely interwoven, not just a blog bolted on
A bespoke interface the theme layer cannot express — configurators, complex filtering, unusual purchase flows
A technically capable in-house team who will own the frontend long term
Performance requirements where you have measured that a well-built theme cannot meet them

Bad reasons

“We want the site to be faster.” Fix the apps and images first. That is cheaper and usually sufficient.
“Our theme feels limiting.” A custom theme removes theme limits at half the cost and keeps the editor.
“It’s more modern.” Architecture fashion is not a business case.
“Our developers want to work in React.” A real consideration for hiring, and not a reason to double the build cost.

The honest cost picture

Roughly double a custom theme build for equivalent scope, and the ongoing cost stays higher permanently, because routine changes that were self-service become developer tasks.

Add storefront hosting, which the commerce platform no longer provides, and a second deployment pipeline to maintain.

For an organisation with the team and the reasons, that is money well spent. For a store that wanted a faster site, it is a very expensive route to a problem that had a cheaper solution.

How we advise

We ask two questions.

First: what specifically can you not do today? If the answer is a list of theme frustrations, a custom theme solves it for less. If the answer is genuinely architectural — multi-brand, bespoke interfaces, deep content integration — headless is the honest answer.

Second: who changes the site day to day? If marketing currently edits pages themselves and expects to continue, headless removes that, and that consequence needs accepting before the build rather than discovered after it.

What a headless project actually involves

If you have decided the reasons are real, this is the shape of the work, which differs substantially from a theme build.

Frontend framework choice. Hydrogen if staying close to Shopify’s tooling, or a framework your team already knows. The deciding factor should be who maintains it long term, not which is technically most interesting.

Data layer design. What gets fetched at build, what gets fetched per request, and what gets cached where. This is the decision that determines whether the storefront is fast, and it is easy to get wrong in ways that only appear under load.

Content management. Without the theme editor, marketing needs somewhere to edit content. That usually means adding a content management system, which is a second system to run and a cost that is often omitted from the estimate.

Cart and checkout. The cart is yours to build; checkout usually remains with the platform. The handover between them needs care, and it is where headless builds most often introduce bugs.

Preview and staging. Content editors expect to see changes before they publish. Building that is straightforward with a theme and real work headless.

Hosting and deployment. A pipeline, an environment, monitoring, and somebody who owns it.

None of that is exotic, and all of it is work that a theme build simply does not have.

Questions before committing

Who maintains the frontend in three years? Headless storefronts are ordinary web applications with ordinary maintenance needs — dependency updates, framework upgrades, security patches. If the answer is “the agency who built it”, make sure that arrangement is real and funded.

What happens to the apps you rely on? Check each one for headless support before committing, not after.

How will marketing edit content? Answer this concretely. “Through the CMS” needs to mean a specific CMS with a specific cost.

Have you measured what a good theme could achieve? If performance is the driver, get a proper measurement first. We have seen headless projects commissioned to solve a problem that an app audit and correct image handling would have solved for a fraction of the cost.

Our honest position

We build headless storefronts, and we recommend against them more often than we recommend them.

That is not caution for its own sake. It is that the reason people ask is usually performance or design flexibility, and both are more cheaply addressed by a custom theme with a disciplined app stack. The situations where headless genuinely wins — multi-brand, deep content integration, bespoke interfaces — are real and specific, and they are worth naming rather than assuming.

If you can name yours, headless is a good decision. If you cannot, it is an expensive one.

What it actually costs to run an online store

hello@w3nuts.co.uk (Kay Patel) — Wed, 17 Jun 2026 00:00:00 GMT

Build cost gets scrutinised. Running cost rarely does, and it is the larger number over any meaningful period. This is the full list, including the parts that accumulate without anyone deciding to let them.

The cost lines

Platform

On a hosted platform this is the monthly subscription, and it is the most predictable line on the list. Plan tiers usually change what you can do rather than how much traffic you can take.

On a self-hosted platform there is no licence, but see hosting below.

Payment processing

Usually the largest variable cost, and it scales directly with success. Two components: the processor’s percentage and fixed fee, and on some platforms an additional platform fee unless you use their own payment product.

That platform fee is worth calculating properly rather than dismissing. On a store doing meaningful volume it is a substantial annual number, and it is the main financial argument for self-hosted platforms.

Apps and extensions

This is the line that grows quietly, and the one we most often find has never been reviewed.

The pattern is consistent. A store adds an app to solve a real problem. The problem passes, or the feature gets built into the platform, and the app stays. Repeat a dozen times over two years and you have a monthly total nobody chose.

There is a second cost too. Every app that injects a script adds render-blocking weight to every page, including pages where it does nothing. So the subscription total understates the real cost.

Audit the list twice a year. It is routinely the fastest saving available on a store, and it usually improves performance at the same time.

Hosting

Zero on hosted platforms. Real and growing on self-hosted ones, where you need enough capacity for object caching, a staging environment and backups — which rules out the cheapest tiers.

Budgeting the minimum here is a false economy that produces the slow-store problem covered in running WooCommerce properly.

Domain, email and certificates

Small, annual, and universally forgotten until renewal. Business email at per-seat pricing adds up on a growing team.

Transactional messaging

Order confirmations, shipping notices, password resets, abandoned-cart sequences. Free tiers cover early volume, then stop. Stores typically discover this during a busy month, which is the worst time to be reconfiguring an email provider.

Maintenance

On self-hosted platforms, someone must apply updates, test them, and keep backups. Whether that is a retainer or in-house time, it is a real recurring cost and pretending otherwise is how stores end up unmaintained.

Development

Stores change. New products, seasonal content, a checkout fix, a campaign landing page, an integration with a system the business just adopted.

Businesses that budget nothing for this end up with a store frozen at its launch state, slowly diverging from how the business actually trades. The cost of not changing is invisible and larger than the cost of changing.

The three-year convergence

Hosted platforms are cheaper in year one. The gap narrows every year, because app subscriptions accumulate while self-hosted extension costs are often one-off licences.

Self-hosted platforms cost more to set up properly and stay flatter, provided somebody owns maintenance. If nobody does, the eventual cost is a security incident, which is not a line item anyone budgets for.

Over three years the totals land closer together than either camp claims. Choose on fit and maintenance capacity, not on a cost comparison that only counts one column.

Three worked examples

Illustrative shapes rather than real client figures, to show how the balance shifts as a store grows.

A new store, first year

Platform subscription on an entry tier. Payment processing on modest volume. Three or four apps, chosen carefully. A domain and one business email seat. Transactional email comfortably inside a free tier.

The dominant costs are not on this list. They are photography, initial content, and whatever brings the first traffic. Store running costs at this stage are genuinely small, and the common mistake is over-investing in tooling before there is anything to tool.

An established store, steady trade

Platform subscription, possibly on a higher tier. Payment processing now a substantial monthly number. Eight to fifteen apps, several of which nobody has reviewed since installing. Transactional email now paid. A developer engaged periodically for changes.

This is where the app audit pays for itself. It is also where development budget starts mattering, because the store now needs to change regularly and every change that requires a quote is a change that gets deferred.

A growing store, multiple markets

Higher platform tier or Plus. Payment processing across currencies with additional fees. A larger app stack, plus at least one genuinely expensive specialist tool. Meaningful transactional volume. Either a retainer or an in-house hire, because ad-hoc development no longer keeps up.

Costs are now dominated by people rather than software. The subscriptions are noise against the development and operational spend, which is a different budgeting conversation entirely.

Costs that scale, and costs that do not

Useful when forecasting, because they behave very differently.

Scales with revenue: payment processing, transactional messaging volume, hosting on a self-hosted store, some usage-priced apps.

Scales with complexity: development time, integrations, the number of templates and markets to maintain.

Scales with neglect: technical debt, an unaudited app stack, deferred updates. This category is invisible until it is expensive.

Fixed regardless: platform subscription, domain, certificates, most app subscriptions.

The third category is the one to watch, because nothing on a dashboard reports it. A store that has not been maintained for two years has a real, accumulating cost that appears all at once when something finally breaks.

The subscription audit, step by step

Half a day, twice a year, and it is the highest-return administrative task available on a store.

List every recurring charge, including anything on a personal card or a departmental budget. Check the payment provider statement rather than relying on memory.
For each, answer: what does it do, when did we last use it, has the platform since built this in, and does it inject a script on every page?
Cancel anything that fails all four. There is usually more than you expect.
Check what removal leaves behind. Uninstalled apps frequently leave code in the theme — detail in the apps slowing your store.
Measure the store before and after. Both the monthly total and the page weight.
Write down what remains and why, so the next audit starts from a list rather than from scratch.

Most stores that have never done this find both money and speed in the same afternoon, which is a rare combination in this line of work.

Project or retainer?

For continuous small work, a retainer is usually better value — each separate project carries scoping and context-switching overhead that a retainer absorbs.

For a single defined piece of work with a clear end, a project quote is better. The deciding factor is not size, it is whether the work is continuous or finite.

Our own answer to this is ProNuts, published at a real monthly price rather than “contact us for pricing”, with the exclusions listed openly. If your need is one defined project, we will quote it as a project instead.

A budgeting exercise

List every recurring charge against the store. Include the ones on someone’s personal card. For each, answer:

What does this do?
When did we last use it?
Has the platform since built this in?
Does it inject a script on every page?

On most stores, that exercise finds money and speed in the same afternoon.

Costs outside this list

Deliberately excluded above because they are not store running costs, but they consume the same budget and are worth naming so the picture is complete.

Photography. The most consistently underinvested line in ecommerce. Product pages fail more often on missing information and poor imagery than on anything technical, and good photography outperforms most development work per pound spent.

Content. Product descriptions, category copy, editorial. Someone has to write it, and “we’ll do it internally” usually means it does not happen.

Marketing. Paid acquisition, email, affiliates. Frequently the largest number in the whole business, and entirely outside this article.

Fulfilment and returns. Packaging, postage, warehousing, and the cost of goods coming back. In some categories returns are the difference between profit and loss.

Customer support. Whether that is somebody’s time or a dedicated person.

We separate these because store running costs get conflated with the cost of running a business, and the conflation makes the technology look either cheap or ruinous depending on which side of the line you draw it.

Reducing what you spend

In rough order of return.

Audit the subscriptions. Covered above. Fastest win available, and it improves speed at the same time.

Consolidate overlapping tools. Most stores run two things that do the same job because each was added to solve a specific problem at a different time.

Check your payment processing rate. Rates are negotiable at volume and most merchants never ask. This is a phone call, and on a store doing real numbers it is a meaningful annual saving.

Move recurring work into automation where the payback is clear — see what to automate first.

Fix things properly rather than repeatedly. A recurring manual workaround has a cost that never appears on any invoice, and it usually exceeds the cost of fixing whatever causes it.

Do not economise on hosting if you are self-hosted. It is the one line where spending less reliably costs more, in performance, in incidents, and eventually in an emergency migration.

A budgeting template

For an annual review, list against each line: what you pay, whether it scales with revenue, when you last reviewed it, and what would happen if you removed it.

Line	Scales with	If removed
Platform subscription	Plan tier	Store stops
Payment processing	Revenue	Store stops
Apps and extensions	Nothing	Varies — check each
Hosting	Traffic	Store stops
Transactional email	Volume	Customers get no confirmations
Domain and certificates	Nothing	Store stops
Maintenance	Complexity	Store decays
Development	Ambition	Store freezes

That last column is the useful one. Anything where the honest answer is “nothing much” has been identified, and anything where the answer is “the store stops” is not a candidate for cutting regardless of cost.

The one habit worth adopting

Put a recurring reminder in the calendar, twice a year, to review every subscription against the store.

That single habit prevents the most common cost problem in ecommerce, which is not any individual expensive tool. It is the slow accumulation of a dozen small ones that each made sense at the time, that nobody has revisited, and that collectively cost more than anybody realises while making the store measurably slower.

Half a day, twice a year. It is the highest-return administrative task available to a store owner.

A closing note

The most expensive line on any store is rarely the one anybody worries about. It is the accumulated cost of small decisions nobody revisited — the app installed for a campaign that ended, the plan tier upgraded for a feature never used, the maintenance deferred until it became an incident.

None of those appear on a budget as a problem. All of them appear eventually as a number.

Where the money usually is

Two things, on nearly every store we audit.

An app or extension stack that has never been reviewed as a set, costing more than anyone realises and slowing the store while it does it. And a payment processing rate that was agreed when the business was much smaller and has never been renegotiated since.

Neither requires development work to address. Both are worth more than most optimisation projects.

What to automate in an ecommerce business first

hello@w3nuts.co.uk (Samir Kaila) — Wed, 03 Jun 2026 00:00:00 GMT

Almost everything written about AI in ecommerce is vague enough to be useless. This article names specific automations, ranks them by effort against payback, and says which ones we recommend against.

Why the first automation should not be a chatbot

It is what most people ask for first, and it is close to the worst place to start.

A customer-facing assistant is the most visible AI project available, which is exactly the problem. It sits in front of customers, where mistakes are expensive and public. It is high effort to build properly, because doing it well requires retrieval over your own content rather than a generic model. And it pays back slowly, because deflection rates take months to establish.

The highest-return first automation is nearly always internal and invisible. Nobody sees it. It saves hours every week from the day it ships. And when it makes a mistake, somebody catches it before a customer does.

The ranking

Automation	Build effort	Payback speed	Risk if it fails	Start here?
Product description first drafts	Low	Immediate	Low — caught in review	Yes
Inventory sync between systems	Low–medium	Immediate	Medium — oversells	Yes
Order routing and exception flagging	Medium	Fast	Medium — delayed orders	Yes
Search-gap reporting	Low	Slow	None	Yes, cheap
Alt text generation for catalogue images	Low	Slow	Low	Yes, cheap
Review response drafting	Low	Slow	Low	Later
Product recommendations	Medium	Medium	Low	Later
Customer support assistant	High	Slow	High — customer-facing errors	Not first
Automated pricing decisions	High	Unclear	Very high	No

The last two rows are the two things clients most often ask for first.

The three to start with

Product description first drafts

Given real product data and three example descriptions in your house style, a model produces usable first drafts at a fraction of the time writing them from scratch takes.

Given only a product name, it produces plausible fiction — which on an ecommerce site means inaccurate claims about a physical object you then have to ship. That is a commercial and legal problem before it is an SEO one.

Every generated description needs a human pass before publication, and we build that step into the workflow rather than leaving it to discipline.

Inventory sync

Usually no language model at all. A webhook fires on order creation, logic decides what updates where, and systems stay consistent. Shopify Flow and WooCommerce’s Action Scheduler handle much of this natively.

Payback is immediate and obvious: it removes a recurring manual reconciliation and it stops overselling, which costs real money in refunds and goodwill.

Order routing and exception flagging

Rules decide fulfilment destination; anything unusual gets flagged for a human rather than silently processed. The value is less in the routing than in the flagging — surfacing the twenty orders a week that need attention, out of the two thousand that do not.

What we will not automate

Stated plainly, because the boundary matters more than the capability list:

Pricing decisions. Automated repricing without oversight fails in ways that are expensive and public.
Final customer-facing copy without review. First drafts yes; publication no.
Anything with legal or safety consequences — returns entitlements, product safety claims, regulated categories.
Fraud or chargeback decisions on model output alone.
Support escalation. A customer asking for a human gets a human, immediately, every time.

Retrieval, and why it decides quality

If you do build a customer-facing assistant, the architecture question that matters is whether it answers from your content or from the model’s general knowledge.

Retrieval-augmented generation means the system searches your own policies, product data and documentation first, then asks the model to answer using what it found. That is the difference between an assistant that quotes your actual returns policy and one that invents a plausible-sounding policy you are then held to.

For any customer-facing use, retrieval is not an optimisation. It is the requirement.

Data handling

Worth being explicit, because it is every buyer’s unspoken second question.

Name which provider processes what before building anything. Do not send customer personal data to a model unless the task genuinely requires it, and minimise the fields when it does. Build retrieval over content you control. Confirm each provider’s retention and training terms in writing during scoping, because those terms change.

As data controller, the compliance obligations remain yours. Our job is to document the processing accurately so your records are correct.

Measure it, or lose it

Agree before building: what does this replace, and how will we know it worked? Hours saved per week, tickets deflected, error rate against the manual baseline. Record the baseline first.

That number is what defends the automation the first time it gets something wrong — and it will get something wrong. Automations without a number attached get switched off within a quarter, usually after one visible failure that nobody can weigh against the invisible successes.

How to scope an automation properly

Most automation projects go wrong at scoping rather than at build. These are the questions we work through before quoting anything.

What exactly does a person do today? Step by step, including the judgement calls. If nobody can describe the manual process precisely, it is not ready to automate — you would be encoding a process nobody understands.

How often, and how long does it take? This produces the hours-saved figure that decides whether the work is worth doing. “It takes ages” is not a number.

What does the input look like, really? Not the ideal case. The messy supplier feed with inconsistent units, the orders with missing fields, the customer messages that contain three questions at once. Automation fails on the edge cases, and the edge cases are where the current manual effort actually goes.

What happens when it gets it wrong? Who notices, how quickly, and what does it cost? This determines how much review the workflow needs, which is often the largest part of the design.

What is the fallback? Every automation needs a manual path for when it fails or is switched off. Building something the business cannot operate without, that nobody can operate manually, is a fragility you do not want.

Who owns it afterwards? Automations need occasional attention — an API changes, a format shifts, a provider deprecates something. An unowned automation degrades silently.

The four categories, and how they differ

Grouping automations by where they sit clarifies both effort and risk.

Content generation. Product descriptions, alt text, category copy, translation. Low risk when reviewed, immediate payback, and the quality is entirely determined by the quality of the input data. Covered in detail in AI product descriptions.

Data movement. Inventory sync, order routing, catalogue imports, reporting pipelines. Usually no language model at all — this is integration work. Highest reliability, most predictable payback, least glamorous.

Customer interaction. Support assistants, order enquiry handling, recommendations. Highest risk because errors are public, highest effort because doing it properly requires retrieval over your own content, slowest payback.

Analysis. Performance summaries, anomaly detection, search-gap reports, sentiment analysis on reviews. Low risk, slow payback, genuinely useful for the person running the store. Frequently the most under-appreciated category.

A sensible sequence works through those roughly in order: content, then data, then analysis, then customer interaction last.

What good looks like six months in

If automation is working, six months later you should be able to say:

Which specific tasks stopped being done manually, named
How many hours a week that represents, measured rather than estimated
What the error rate is, compared against the manual baseline
Who owns each automation and when it was last reviewed
Which ones you switched off and why

That last one matters. Some automations do not earn their keep, and being willing to remove them is what stops the automation stack accumulating the way app subscriptions do.

If instead the answer is “we have AI now” with no numbers attached, the project did not have a measure defined at the start, and it will be difficult to defend the next time somebody reviews costs.

Cost, and how to think about it

We deliberately have not quoted figures for individual automations, because the range within each category is wider than the gap between categories. A product-description workflow for two hundred products and one for forty thousand are different projects.

What is stable is the shape of the cost:

Build cost scales with how messy the input data is, not with how clever the automation sounds. Clean, structured product data makes a description workflow straightforward. Inconsistent data spread across three systems makes the same workflow largely a data-cleaning project.

Running cost is per-operation for anything involving a model, and effectively zero for rules-based integration work. This is one reason we push toward the latter where it will do the job.

Review cost is ongoing and frequently forgotten. If every output needs a human pass, that time is part of the automation’s real cost and it should be in the comparison.

The useful calculation is not “what does this cost” but “what does this cost against the hours it removes, including review”. An automation saving four hours a week is worth considerably more than one saving four hours a month, regardless of which was cheaper to build.

Starting from where you are

If you have never automated anything, the sequence that works:

List the repetitive tasks. Anything somebody does the same way every time.
Time them honestly for a fortnight. Estimates are consistently wrong.
Pick the one with the highest hours and the lowest risk. That is almost always internal.
Record the baseline — time taken, error rate, volume.
Build the smallest version that works. Not the complete vision.
Measure after a month and decide whether to extend or stop.

That sixth step is what most automation programmes lack, and it is why so many end up with a stack of half-used tools nobody can justify.

Two things worth saying plainly

Most ecommerce businesses do not need AI to automate their biggest time sinks. Inventory reconciliation, order routing and report generation are integration problems solved with scheduled jobs and API calls. They are less interesting to talk about and they save more hours than anything involving a model.

And an automation nobody owns will decay. APIs change, formats shift, providers deprecate endpoints. Every automation needs a named owner and an occasional review, exactly like the plugins and apps that accumulate on a store. Building one and walking away produces something that works until it quietly does not, which is worse than not building it.

Where to begin this week

Spend an hour listing the tasks somebody on your team does the same way every time. Not the interesting ones — the repetitive ones nobody mentions in meetings.

Time the top three honestly over a fortnight. Then pick the one with the most hours and the least customer-facing risk, and build the smallest possible version of it.

That sequence has a much better record than starting with the automation that sounds most impressive, and it produces a number you can point at when somebody asks what the investment returned.

A closing note

The businesses that get the most from automation are not the ones with the most sophisticated tooling. They are the ones that measured a manual process, replaced a specific part of it, checked whether that worked, and then did it again.

That is unglamorous and it compounds. Buying an impressive tool without the measurement rarely does.

The ecommerce product page checklist

hello@w3nuts.co.uk (Kay Patel) — Wed, 20 May 2026 00:00:00 GMT

Product pages carry more revenue than any other template on a store, and receive less attention than the home page. This is the checklist we work through on every audit.

Before you change anything: record four numbers

A redesign that cannot be measured is a redecoration. Before touching a page, record:

Conversion rate by device. Mobile and desktop separately, always. They behave differently enough that a blended figure hides the problem.
Add-to-cart rate. Distinguishes “they did not want it” from “they wanted it and checkout lost them”.
Checkout completion rate. The proportion who begin checkout and finish.
The funnel drop-off point. Where in the sequence people actually leave.

Without these you cannot distinguish improvement from seasonality, and the conversation after launch becomes an argument about taste.

Is your product page actually the problem?

Worth checking before spending a budget. If paid traffic converts at a fraction of organic, the storefront is probably fine and the targeting is not. If mobile converts far below desktop, look at performance before layout.

We would rather tell you this at audit stage than three months into a redesign.

The checklist

Information — the section that matters most

Is the delivered price clear, including delivery, before checkout?
Is delivery timing stated on the page, not only in the footer?
Are returns terms visible near the buy button, not buried in a policy page?
Is it clear what is physically included?
For anything sized: is there a sizing guide, and does it open without leaving the page?
Are materials, dimensions or specifications present for products where they decide the purchase?
Is it clear how this variant differs from the one beside it?

This section fails more often than all the others combined. Customers abandon because a question went unanswered, and adding the answer near the buy button reliably outperforms rearranging the page.

The cheapest conversion work on most product pages is writing, not designing.

Imagery

Does at least one image communicate scale?
Can images be zoomed without breaking layout?
Is there an image showing the product in use or in context?
Do images have explicit width and height so the page does not shift as they load?
Is the primary image served in a modern format at an appropriate size?

The buy action

Is the buy button reachable without hunting on a phone?
Is variant selection obvious, and does it make out-of-stock combinations clear before selection rather than after?
Does the page communicate stock status honestly?
Are payment methods, including any buy-now-pay-later options, visible before checkout?
Is there a clear route back to browsing that does not lose the cart?

Trust

Are reviews genuine and numerous enough to be credible?
Is there a visible contact route for pre-purchase questions?
Are guarantees or warranties stated where they apply?
Is the returns process described, not merely linked?

Technical and accessibility

Every interactive target at least 44×44 CSS pixels
Contrast meets WCAG 2.2 AA throughout
Visible focus state on every control
Interaction responsiveness stays comfortable during variant selection
Structured data present and matching what is rendered
Page usable at 200% zoom without content loss

Category-specific requirements

The checklist above is universal. These are the additions that matter by category, because a customer buying a jacket asks different questions from one buying a replacement part.

Apparel and footwear. Sizing guide with actual measurements, not just size labels. Model height and worn size. Fabric composition. Care instructions. Fit description — does it run small? Returns terms stated prominently, because return rates in this category are structurally high and customers know it.

Furniture and homeware. Dimensions with a scale reference. Assembly requirements and time. Delivery method — kerbside or room of choice materially changes the purchase. Weight, where it affects handling. Material detail beyond the marketing name.

Electronics and technical products. Full specifications in a structured table rather than prose. Compatibility, stated explicitly. What is in the box, itemised. Warranty terms. Firmware or software requirements.

Food, drink and supplements. Ingredients and allergens, prominently. Nutritional information. Storage and shelf life. Any regulated claims handled carefully — this category has real legal exposure and is not a place for generated copy without qualified review.

Made-to-order and personalised. Lead time stated before the buy button, not in a policy page. What can and cannot be changed after ordering. Whether returns apply at all, since personalised goods often fall outside standard cancellation rights.

Replacement parts and consumables. Compatibility is the entire purchase decision. A fitment lookup, or at minimum an explicit compatibility list, matters more than photography.

How to prioritise what the audit finds

An audit typically produces thirty to sixty findings. Shipping all of them is neither possible nor sensible, so they need ordering.

We score each finding on two axes.

Expected impact — how much of the funnel does this touch, and how strong is the evidence that it matters? A missing delivery estimate on every product page scores high. A slightly cramped related-products row scores low.

Implementation effort — content change, template change, or architectural change. Content changes are usually hours; architectural changes are weeks.

That produces four groups:

	Low effort	High effort
High impact	Do first	Plan properly
Low impact	Do while you are in there	Do not do

The top-left group is where most of the available gain sits, and it is nearly always writing rather than designing — adding delivery timing, stating returns terms, answering the questions support gets asked daily.

The bottom-right group is worth naming explicitly in any audit report, because it stops the same low-value ideas being raised repeatedly.

Measuring afterwards

Compare the same four numbers from the top of this article, over a full traffic cycle rather than a week. A week of data on a store with weekly seasonality tells you about the day of the week.

Three things to be careful of:

Seasonality. Comparing December to January will mislead you regardless of what you changed.

Simultaneous changes. If a redesign ships alongside a campaign, you cannot attribute the result to either. Stagger where you can.

Regression to the mean. If you changed something because a metric was unusually bad, some of the improvement would have happened anyway.

None of this means measurement is futile. It means the honest report says “conversion improved by X, and here is what else changed in the same period” rather than claiming clean causation.

On A/B testing, honestly

Most stores do not have the traffic for statistically meaningful A/B tests on anything except checkout. Testing a product-page variant at two hundred sessions a week produces noise, not evidence, and treating that noise as a result is worse than not testing.

We say which changes we can genuinely test and which are judgement calls informed by established research. Anyone promising rigorous testing on low-traffic product pages is selling certainty they cannot deliver.

What to fix first

If you can only do three things:

Put delivery cost and timing on the page. Unexpected shipping cost is the most common abandonment cause in every study of the subject.
Answer the top three pre-purchase questions your support team receives, in text, near the buy button.
Make the buy button reachable on mobile without scrolling back up.

None of those require a redesign. All of them are usually cheaper than one.

A worked example

A product page we audited recently, anonymised. A mid-priced consumer product, healthy traffic, conversion well below what the category would suggest.

What the page had: eight studio photographs on white, a well-written brand story, a price, a buy button, and a related-products carousel.

What it did not answer: how much delivery cost. When it would arrive. What the returns terms were. What was physically in the box. How the two colour variants differed beyond colour. What the product’s dimensions were.

The design was genuinely good. The photography was expensive. And a customer could not work out what it would cost delivered, or what would happen if it was wrong.

What we changed first: added delivery cost and estimated arrival above the buy button; added a two-line returns summary beside it; itemised box contents; added one photograph with a scale reference.

None of that was design work. It was four pieces of writing and one photograph. It is the pattern we see repeatedly — the page looked finished and was not informationally complete, and those are different things that get conflated.

Where the checklist comes from

Nothing above is novel. It comes from three sources, and it is worth naming them so you can go deeper than this article.

Published ecommerce UX research, particularly Baymard Institute, which has run large-scale usability testing across ecommerce interfaces for years. Their findings on checkout and product pages are the closest thing the field has to an evidence base.

Accessibility standards. A surprising amount of good ecommerce UX is simply WCAG 2.2 applied properly — adequate target sizes, visible focus, sufficient contrast, no information conveyed by colour alone. Building accessibly produces better product pages for everyone, not only for people using assistive technology.

Support tickets. The cheapest research available and the most ignored. The questions your support team answers repeatedly are, by definition, questions your product pages are failing to answer. Reading a month of tickets will tell you more about your product pages than any audit.

That third source deserves emphasis. If you do nothing else from this article, ask whoever handles customer enquiries for the five questions they answer most often, and put those answers on the page.

What we would not bother with

Worth stating, because audit reports tend to list everything and prioritise nothing.

Exit-intent popups on product pages. They interrupt at the moment of consideration and the recovered conversions rarely justify the annoyance or the script weight.

Countdown timers on evergreen products. Customers recognise them, and a timer that resets on refresh damages trust more than urgency helps.

Live visitor counters. Same reasoning. If the number is real it is usually unimpressive; if it is fabricated it is dishonest.

Extensive related-product carousels. They push the information customers actually need further down the page, and carousels perform poorly for both engagement and layout stability.

Video autoplay. Weight, distraction, and an accessibility problem for no measured conversion benefit.

Every one of these is regularly proposed and every one costs more than it returns on a typical store.

Running the checklist yourself

You do not need an agency for the first pass. Open your best-selling product page on a phone, and work through the Information section at the top of this article as a customer who has never seen your brand.

Note every question you cannot answer from the page alone. That list is your work queue, ordered roughly by how early in the page the gap appears.

Most stores find between five and fifteen items on that first pass, and most of them are writing rather than design. That is a good afternoon’s work with a real return, and it costs nothing but attention.

A closing note on priorities

If there is one bias worth correcting on product pages, it is the assumption that visual quality and informational completeness are the same thing. They are not, and stores routinely have the first without the second.

Answer the questions first. Then make it beautiful.

Running WooCommerce properly: hosting, caching and security

hello@w3nuts.co.uk (Samir Kaila) — Wed, 06 May 2026 00:00:00 GMT

WooCommerce gets blamed for problems that belong to its hosting. The plugin is mature, widely audited and runs some very large stores. What it does not do is specify its own infrastructure, and that gap is where most disappointing WooCommerce stores are born.

Why is WooCommerce blamed for hosting problems?

Because the failure looks like a platform failure. The store is slow, the admin is sluggish, checkout hangs under load — and the visible thing is WooCommerce.

Underneath, the pattern is nearly always the same: a store on shared hosting with no object cache, no CDN, an undersized database and PHP configured for a brochure site. The same store on adequate infrastructure performs completely differently, with no code changes at all.

Specify the infrastructure before you blame the software.

What a WooCommerce store actually needs

Layer	Requirement	Why
PHP	8.2 or later, generous memory limit	Performance and supported security patches
Database	MySQL 8 or MariaDB 10.6+	Query performance, proper indexing
Object cache	Redis or Memcached	The single biggest win — see below
Page cache	With correct exclusions	Never cache cart, checkout or account pages
CDN	In front of static assets	Latency for geographically spread customers
Staging	A real environment, not a copy on the same server	Testing updates before they touch production
Backups	Automated, offsite, and restore-tested	The only backup that counts is one you have restored
TLS	With HSTS	Baseline, and required for payment processing

Object caching is the largest single win

WordPress makes a large number of repeated database queries per request. Without an object cache, every one hits the database every time. With Redis, the repeated results are held in memory.

On the stores we have taken over, enabling Redis has routinely done more for admin and cart response times than any amount of frontend work. It is a hosting configuration, not a code change, and most hosts do not enable it by default.

If you take one thing from this article: find out whether your store has a persistent object cache. Many owners discover it does not.

High-Performance Order Storage

Historically, WooCommerce stored orders in the WordPress posts table alongside pages and blog posts. That works until order volume grows, at which point order queries and content queries compete for the same indexes.

High-Performance Order Storage moves orders into purpose-built tables. If your store predates it and still uses legacy storage, migrating is a configuration change rather than a rebuild, and the effect on admin performance at volume is substantial.

The plugin problem

Every plugin is code somebody else maintains, running inside your store, with full database access.

The failure we see most often is not a hacked site. It is a store with forty plugins where three do broadly the same job, two have been abandoned by their authors, and nobody can say which one owns the checkout behaviour that is misbehaving.

Our working rules:

Before installing a plugin, ask whether fifty lines of custom code would do it. Fifty lines we wrote can be read, tested and removed. A plugin cannot always be.
Delete rather than deactivate. Deactivated plugin code still sits on disk and can still be exploited.
Check the last update date and the support forum before installing. An abandoned plugin is a scheduled security incident.
Custom business logic belongs in a versioned plugin, not in the theme’s functions.php, so it survives a theme change and can be code-reviewed and rolled back.

A maintenance routine that works

Self-hosting means somebody owns this. Not “the team” — a named person.

Weekly: check for security releases and apply them after a staging test. Review error logs. Confirm backups ran.

Monthly: apply routine core, plugin and theme updates on staging, test checkout end to end, then deploy. Review the plugin list and remove anything unused.

Quarterly: restore a backup to staging and confirm it actually works. Review database size and clean up expired transients and old revisions. Audit admin user accounts and remove people who have left.

Annually: review PHP and database versions against current supported releases. Re-check that every active plugin is still maintained.

That routine is unglamorous and it is the entire difference between a WooCommerce store that runs for five years and one that becomes a liability in eighteen months.

Security, concretely

Enforce strong authentication on every admin account, with two-factor where possible
Limit login attempts and change the default login URL
Never run an administrator account for day-to-day content editing
Keep file permissions tight and disable file editing from the WordPress admin
Put a web application firewall in front of the site
Keep offsite backups, because a backup on the compromised server is not a backup

None of this is exotic. All of it is skipped regularly.

What you get in exchange

It is worth restating what this work buys, because the maintenance burden is real and the benefit should be too.

You hold the database. There is no per-transaction platform fee. No vendor can change your checkout underneath you, deprecate a feature you depend on, or restrict an export. You can move hosts, modify anything, and integrate with systems no platform has anticipated.

For a business with technical capacity or a maintenance retainer, that is an excellent trade. For a business with neither, it is a bad one — and we will say so rather than sell you a store nobody will look after.

Getting the database in order

Databases on long-running WooCommerce stores accumulate weight nobody is watching. A periodic clean-up is safe, quick and frequently produces a noticeable improvement.

Expired transients. Temporary cached values meant to expire that often do not clean up properly. On older stores these can number in the tens of thousands.

Post revisions. WordPress stores every save of every page and product as a revision, indefinitely by default. Useful for a week, dead weight after a year. Limiting how many are retained is a one-line configuration change.

Orphaned metadata. When a plugin is removed, its data usually stays. Over years of installing and removing plugins, a store accumulates metadata belonging to code that no longer exists.

Autoloaded options. The one that matters most, because these load on every single request. Plugins add them freely and rarely clean up. Checking the total size of autoloaded data takes a minute and is frequently revealing.

Order and session tables. Abandoned sessions and expired carts accumulate. WooCommerce has scheduled clean-up for some of this; confirm it is actually running rather than assuming it.

Do this on staging first, with a tested backup, and measure before and after so you know whether it helped.

Who owns this, in practice

Everything above needs an owner. Not a team, not whoever notices — a named person with the access and the time.

The three arrangements that work:

In-house. Someone technical whose responsibilities explicitly include the store, with time allocated rather than assumed. Works well when the person exists and stays.

A maintenance retainer. An external party with a defined scope, a schedule, and accountability. Works well when the scope is written down rather than implied.

A hybrid. Someone internal owns content and monitoring; an external party owns updates, security and infrastructure. This is the arrangement we see succeed most often, because it puts each responsibility with whoever is best placed to hold it.

The arrangement that does not work is the implicit one, where everybody assumes somebody else is watching. That is how a store goes fourteen months without an update.

Choosing a host: the questions to ask

Hosting salespeople answer the question you asked, not the one you meant. These are phrased to get useful answers.

“Is a persistent object cache available, and is it enabled by default?” Not “do you have caching” — that gets you a yes about page caching. Redis or Memcached, specifically, and whether you have to request it.

“What PHP versions do you support, and what memory limit?” You want 8.2 or later and generous memory. A 128MB limit will cause problems on a real store.

“Is there a staging environment, and how do I push changes between staging and production?” A staging site you cannot easily sync from production is barely a staging site.

“How are backups taken, where are they stored, and how do I restore one?” Offsite matters. A backup on the same server does not survive the failure mode you are protecting against.

“What happens during a traffic spike?” Specifically: do you throttle, queue, or fall over? Worth knowing before your busiest trading day.

“Is WooCommerce specifically supported?” Generic WordPress hosting often page-caches aggressively without excluding cart and checkout, which breaks stores in ways that look random.

What a staging environment actually needs to be

“We have staging” covers a wide range of quality.

A staging environment worth having is a full copy of production — same PHP version, same database engine, same plugin set, same theme, with representative data volume. Testing an update against three sample products tells you very little about how it behaves against forty thousand.

It must be isolated, so nothing done there can send an email to a real customer or charge a real card. Payment gateways in test mode, email interception enabled.

It must be refreshable, so you can pull production down to staging on demand rather than working against a copy that diverged six months ago.

And it must actually be used. A staging environment that exists but is bypassed under time pressure provides no protection.

Reading the signs your store is decaying

Self-hosted stores rarely fail suddenly. They degrade, and the signals appear well before anything breaks.

Nobody can say when updates were last applied. The single clearest indicator.
The plugin list contains things nobody recognises.
Admin has become noticeably slower over months, which usually means database growth nobody is managing.
PHP or database versions are approaching or past end of life.
Backups run but have never been restored. Untested backups fail at exactly the wrong moment.
Changes are made directly on production, because staging is broken or absent.
The person who built it has moved on and nothing was documented.

Any two of those together mean the store needs attention before it needs rescuing. Attention is considerably cheaper.

One thing to do this week

If this article is more than you have capacity to act on, do this single check.

Log into your site health information, or ask your host, and find out whether a persistent object cache is active. Not page caching — object caching, meaning Redis or Memcached.

If the answer is no, that is very likely your largest available performance improvement, it costs a hosting configuration change rather than development work, and it will improve the admin experience for whoever runs the store every day.

Everything else in this article can wait behind that one answer.

What good looks like

A well-run WooCommerce store, summarised:

Object caching enabled and verified
PHP and database on current supported versions
Fewer than fifteen active plugins, every one of them identifiable
Orders on High-Performance Order Storage
Staging environment that mirrors production and is actually used
Backups running offsite, restored at least once in the past quarter
Updates applied on a schedule with a named owner
Page caching with correct cart and checkout exclusions
Custom logic in a versioned plugin, not the theme
Someone who can answer “when was this last updated?” without checking

None of that is exotic. All of it is the difference between WooCommerce being an excellent choice and an expensive regret.

The complete guide to building a custom Shopify store

hello@w3nuts.co.uk (Kay Patel) — Wed, 22 Apr 2026 00:00:00 GMT

Most guides to building a Shopify store describe the admin interface. This one describes the project: what happens in which order, what decisions get made when, and where builds go wrong.

Should you build custom at all?

Start here, because the honest answer is often no.

A configured theme is the right choice when your catalogue is modest, your checkout is standard, and your requirements fit what the theme’s settings already expose. It launches in weeks rather than months and costs a fraction as much. If that describes you, buy a good theme and spend the difference on photography.

A custom build earns its cost when:

You have many templates that need to behave differently from one another
Your product data has structure a theme cannot represent
You are integrating with systems the theme knows nothing about
Your brand needs a storefront that does not look like a theme
You have outgrown a theme and are fighting it on every change

Stage 1 — Discovery and platform fit (1 week)

We audit the catalogue, order volume, integrations and business rules to confirm Shopify is the right platform at all, and document every place it will need extending.

The output is a list of requirements Shopify handles natively, requirements needing an app, and requirements needing custom code. That third list is what drives the estimate, and producing it before quoting is what stops a project discovering its real scope in week six.

Stage 2 — Information architecture and UX (1–2 weeks)

We map collections, navigation, filtering and the checkout path, then wireframe the templates carrying the most revenue: home, collection, product and cart.

Note the ordering. The home page is usually the least commercially important template on a store and it consistently receives the most attention. Most sessions that convert arrive on a product page from search or an ad, and never see the home page at all.

Stage 3 — Design (2 weeks)

We design the full template set in Figma against a component library, so every page is assembled from the same reusable parts rather than designed in isolation.

Designing against a component library rather than page by page is what keeps the build predictable. When a designer invents a new card style on the fourth template, that is a new component, new code, new test surface, and new maintenance.

Stage 4 — Build (3–4 weeks)

The theme is developed in Liquid using Online Store 2.0 sections, apps and APIs are wired up, and markets, shipping and tax are configured for your selling regions.

Some specifics worth knowing:

Sections everywhere. Online Store 2.0 allows sections on every template, not only the home page. Building this way means your team can rearrange layouts afterwards without a developer. It costs slightly more upfront and saves continuously.

Metafields before apps. A great deal of what stores install apps for is structured product data — specifications, care instructions, sizing. Metafields and metaobjects handle this natively, with no monthly subscription and no injected script.

Shopify Functions for logic. Discount, shipping and payment customisation logic runs as Shopify Functions rather than as checkout scripts. This is the supported route and it survives platform updates.

Theme app extensions over script injection. When an app must add frontend behaviour, a theme app extension is scoped and removable. A script injected into the theme is neither, and it is how stores accumulate code nobody can identify two years later.

Stage 5 — Migration and QA (1–2 weeks)

Products, collections, customers and order history migrate through the Admin API. Then the testing, which matters more than the transfer.

Two things reliably break, and neither is the catalogue.

The first is URL structure. Shopify enforces /products/, /collections/ and /pages/ prefixes, so almost every legacy URL changes. Every one needs a redirect. Skipping this is the most common way a migration loses search traffic, and the loss appears three weeks later when it looks like an algorithm update rather than a self-inflicted wound.

The second is customer passwords. They cannot be migrated — the hashes are not portable. Every customer must reset. That means the reset email needs to be written, scheduled and tested before launch, not discovered afterwards when support tickets arrive from people who cannot log in.

Testing covers checkout across devices, payment methods, tax rules for each selling region, and every transactional email. Email templates are the most commonly forgotten item on a migration checklist.

Stage 6 — Launch and optimisation (1 week and ongoing)

We launch, then watch Core Web Vitals and checkout completion for the first weeks and prioritise fixes based on where real users actually drop out.

A launch is a starting point for measurement, not the end of the project. The store as launched is a hypothesis; the first month of real traffic is the test.

What it costs to run afterwards

Budget explicitly for these, because they recur:

Shopify’s platform subscription — predictable
Transaction fees — unless using Shopify Payments
App subscriptions — the largest and least predictable line, and the one nobody audits
Development — proportional to how often the store changes

App costs deserve particular attention. Each app looks inexpensive monthly. Twelve of them do not. We audit the app list at launch and again at six months, and removing unused apps is routinely the fastest performance win available.

What we need from you, and when

The most common cause of a build running late is not development. It is waiting for content.

Before stage 2 (information architecture):

A complete product list with categories, even in spreadsheet form
Any existing analytics access, so decisions are informed by real behaviour
A list of every system the store must talk to

Before stage 3 (design):

Brand assets — logo files, fonts, colour references
Product photography, or a date when it will exist
Any imagery you have rights to use

Before stage 4 (build):

Access to the systems being integrated, with credentials that work
Final decisions on shipping rates and tax configuration
Legal pages — privacy, terms, returns

Before stage 5 (migration):

The complete catalogue export from the current platform
A decision on what happens to order history
Sign-off on the redirect map

Photography is the single most common delay, and it delays stage 3 rather than stage 6, which means it stops everything behind it. Starting photography early is the cheapest schedule insurance available on any ecommerce project.

Common ways Shopify builds go wrong

Patterns we have seen repeatedly, all avoidable.

Designing the home page first, and at length. It is usually the least commercially important template. Product and collection pages carry the revenue, and they receive whatever attention is left.

Choosing apps during the build rather than before. Each app added mid-build changes the frontend, sometimes conflicting with what was designed. Decide the app stack in discovery.

Treating the redirect map as a launch-week task. It belongs in the migration stage, sized properly, with time to test.

No staging discipline. Shopify’s theme preview is not the same as a full staging environment with representative data. Test with realistic catalogue volume, not with three sample products.

Skipping the transactional emails. Order confirmations, shipping notices and password resets all need rebuilding and testing. They are invisible until launch day, when every one of them fires at once.

Nobody owning content. The build finishes and the store waits three weeks for product descriptions. Assign this at kickoff.

The pre-launch testing checklist

What we work through before a Shopify store goes live:

Checkout

Complete a real purchase on desktop and on mobile
Test every enabled payment method, including wallets
Test with a discount code, and with an invalid one
Test with a shipping address in every region you sell to
Confirm tax calculates correctly per region

Catalogue

Spot-check migrated products against the source data
Confirm variant availability displays correctly, including sold-out combinations
Check collections populate as expected
Verify images transferred at full resolution

Email

Trigger and read every transactional email
Confirm sender addresses and reply-to are correct
Check they render on mobile mail clients

URLs and search

Run the full redirect list and confirm each resolves in one hop
Submit the new sitemap
Confirm structured data validates

Performance and accessibility

Core Web Vitals on product and collection templates
Keyboard navigation through the full purchase path
Contrast and focus states throughout

That list takes a day to work through properly and it is the difference between a quiet launch and a week of firefighting.

What happens in the first month after launch

Launch is where measurement starts. The first month typically produces:

Week one — small fixes surfacing from real traffic on real devices. Something always behaves differently in the wild than in testing. This is normal and worth reserving time for rather than treating as a defect.

Week two — the first meaningful Core Web Vitals field data begins accumulating. Lab scores from the build are indicative; field data is what counts.

Weeks three and four — enough checkout data to see where people actually drop out, which is nearly always somewhere the build did not anticipate.

Reserving a small amount of budget for this period is the difference between a store that improves after launch and one frozen at its launch assumptions.

Structuring content so it stays editable

A recurring frustration after launch is that changing anything requires a developer. Much of that is avoidable at build time.

Use sections and blocks generously. Anything the business might want to reorder, hide, or duplicate should be a section with settings rather than hardcoded markup. Hero content, feature rows, trust bars, promotional banners, FAQ blocks.

Expose the right settings, not every setting. A section with forty settings is as unusable as one with none. Expose what will genuinely change — text, images, links, ordering — and hardcode what should not, such as spacing and type scale. Letting a section’s padding be edited is how design systems degrade.

Use metaobjects for repeated content types. Store locations, team members, size guides, ingredient lists. Defined once as a structure, reused across templates, edited in one place.

Document it. A short page explaining which section does what, written at handover, saves an enormous amount of future support time. Most builds skip this and it is close to free to produce.

Where the estimate actually comes from

Useful to understand if you are comparing quotes, because two quotes for “a Shopify build” can differ by a factor of three legitimately.

The drivers, in rough order of impact:

Template count. Not page count — template count. Fifty products using one product template is one template. Four product types needing genuinely different layouts is four.
Integrations. Each system the store must talk to is scoping, building and testing. An ERP integration can exceed the cost of the storefront.
Migration complexity. Catalogue size matters less than data quality. A clean export migrates quickly; inconsistent data needs cleaning first.
Custom logic. Anything Shopify does not do natively.
Content readiness. Not a development cost, but the largest schedule risk.

A quote that does not distinguish these is a guess. When comparing quotes, compare what each assumes about the five above rather than the headline number.

A note on theme updates

One consequence of a custom build worth understanding: you are no longer on an update path.

A purchased theme receives updates from its developer, which you can apply. A custom theme does not, because it is yours. That is not a drawback — it means nothing changes underneath you — but it does mean platform changes need watching. When Shopify deprecates something your theme uses, somebody has to act on it.

In practice this is a small, occasional maintenance item rather than an ongoing burden, and it is the same trade as any bespoke software.

Shopify vs WooCommerce: which should you actually choose?

hello@w3nuts.co.uk (Samir Kaila) — Wed, 08 Apr 2026 00:00:00 GMT

Most comparisons of these two platforms are written by people who sell one of them. We build on both, which means the recommendation comes before the sales conversation rather than after it. We have advised clients to stay on the platform they already had, and we have talked people out of migrations that would have cost them money for no gain.

Here is how the decision actually breaks down.

What is the real difference between Shopify and WooCommerce?

Shopify is hosted software. You rent it, Shopify runs the servers, applies the security patches, handles PCI compliance and guarantees uptime. In exchange you accept the boundaries of what Shopify permits, and you pay monthly.

WooCommerce is a plugin for WordPress. You install it on hosting you control, and the database containing your products, customers and orders is yours outright. Nobody can change your checkout, raise a platform fee, or restrict an export. In exchange, everything that Shopify handles becomes your responsibility.

That is the whole trade. Everything below is a consequence of it.

Does the closed checkout matter to you?

This is the single most decisive technical difference, and it is the one most often discovered too late.

Below Shopify Plus, Shopify’s checkout is closed. You can style it. You cannot change its logic. No custom validation, no bespoke steps, no conditional fields, no business rules that Shopify has not anticipated.

For most direct-to-consumer stores that is fine — the standard checkout is well tested and converts well. But if your business needs any of the following, standard Shopify cannot do it:

Customer-specific pricing agreed by contract
Purchase order or approval workflows
Minimum order quantities enforced at checkout
Custom tax or shipping logic beyond the built-in rules
Age or licence verification as a checkout step

On Shopify, that means Shopify Plus, which is a substantial jump in cost. On WooCommerce, it means writing a plugin.

Ask this question first. It resolves a surprising number of platform decisions on its own.

What does each actually cost over three years?

This is where both camps mislead. Shopify advocates quote the monthly fee and ignore app subscriptions. WooCommerce advocates say “it’s free” and ignore hosting and maintenance.

Cost line	Shopify	WooCommerce
Platform licence	Monthly subscription	None — GPL
Transaction fee	Platform fee unless using Shopify Payments, plus processor fees	Payment processor only
Hosting	Included	Yours — real, and scales with traffic
Security and updates	Handled for you	Yours — retainer or in-house time
Extensions	Mostly monthly subscriptions, recurring	Mostly one-off licences, annual renewal for updates
PCI compliance	Handled	Your responsibility
Developer needed to change things	Sometimes	Often
Cost trajectory as you grow	Rises with apps and plan tier	Rises with hosting and complexity

The pattern we see repeatedly: Shopify is cheaper in year one and the gap narrows every year after, because app subscriptions accumulate quietly and nobody audits them. WooCommerce is more expensive to set up properly and flatter thereafter, provided somebody owns maintenance.

Neither is reliably cheaper. Anyone who tells you otherwise is quoting one column and hiding the rest.

Who will own maintenance in eighteen months?

This is the question that should decide it, and it is not a technical question at all.

A WooCommerce store needs someone to apply core, plugin and theme updates on a schedule, test them on staging first, keep backups they have actually restored from at least once, and notice when a plugin is abandoned by its author. That is a real, recurring commitment.

If you have in-house technical capacity or a maintenance retainer, that commitment buys you genuine ownership and no platform fee. It is a good trade.

If the honest answer is “nobody” — if the site will be built and then left alone until something breaks — choose Shopify. An unmaintained WooCommerce store is a security incident waiting to happen, and it is the most common way we see stores fail.

You want to launch quickly and your requirements fit standard commerce patterns
Nobody on your side will own ongoing maintenance
You sell direct-to-consumer with a conventional checkout
You want predictable monthly costs rather than variable infrastructure ones
You are entering multiple markets and want multi-currency handled for you

Your business logic does not fit standard commerce patterns
You already run WordPress and the store is an extension of an existing content site
Data ownership matters to you commercially or contractually
You object to per-transaction platform fees on principle or at your volume
You have technical capacity or budget for a maintenance retainer

When we tell people not to switch

Migration costs real money and carries real risk. We turn down migration work when:

The current platform is working and the complaint is really about the design, which is cheaper to fix in place
The motivation is cost saving that the three-year comparison above does not support
The store launched under twelve months ago and has not yet been given a fair run
The actual problem is traffic quality or product-market fit, which no platform change will address

How to decide in ten minutes

Work through these in order and stop at the first clear answer:

Do you need to change checkout logic? Yes, and Plus is out of budget → WooCommerce.
Will anyone own maintenance? No → Shopify.
Does your business logic fit standard commerce patterns? No → WooCommerce.
Do you need to launch in under a month? Yes → Shopify.
Still undecided? Choose Shopify. When the decision is genuinely balanced, the lower operational burden wins.

That last point is not a cop-out. A tie means neither platform’s specific strengths are decisive for you, and in that situation the one that demands less of you afterwards is the better business decision.

Where each platform genuinely struggles

Both camps publish strengths. Here are the weaknesses, from building on both.

Shopify struggles with:

Complex B2B below Plus. Company accounts, contract pricing and payment terms are Plus features. Approximating them with apps produces a compromised experience that trade customers notice.
Deeply structured product data. Metafields have improved this enormously, but products with genuinely complex relationships — configurable assemblies, compatibility matrices, kits built from other products — still fight the data model.
Content-heavy sites. Shopify’s blogging and page tools are basic. If editorial is central to how you sell, you will end up either accepting less than you want or running a separate content system.
Cost predictability at scale. The base fee is predictable. The app stack is not, and it grows.

WooCommerce struggles with:

Neglect. Every other weakness is downstream of this one. An unmaintained WooCommerce store degrades in a way a hosted platform does not.
Checkout under load. Cart and checkout cannot be page-cached, so they hit PHP and the database on every request. This is solvable with adequate infrastructure and it is where undersized hosting shows up first.
Plugin conflicts. Two extensions modifying the same hook produce behaviour neither author anticipated, and diagnosing it is genuinely time-consuming.
Upgrade risk. A major WooCommerce release can break an extension you depend on. This is why staging is not optional.

What about the other platforms?

Shopify and WooCommerce dominate the decision, but they are not the only options and it is worth knowing when something else fits.

Adobe Commerce suits large catalogues with genuinely complex B2B requirements and a budget to match. It is powerful and expensive to build and run, and it is overkill for most businesses considering it.

BigCommerce sits close to Shopify with no per-transaction platform fee and strong multi-channel support. Smaller ecosystem, fewer developers who know it well.

Squarespace and Wix are genuinely fine for small catalogues where the store is secondary to the brand presence, and where nobody wants to think about infrastructure. They become limiting quickly if commerce becomes the main business.

We name these honestly rather than pretending the world contains two platforms. If one of them fits you better, that is worth knowing before you commit.

A worked example: two similar businesses, different answers

Two clothing brands, comparable revenue, comparable catalogue size.

The first sells direct to consumers, runs seasonal drops, has no in-house technical staff, and wants to launch a new market this year. Their checkout requirements are entirely standard.

Shopify. Nobody will own maintenance, the multi-market work is handled natively, and nothing about their requirements needs custom checkout logic. Any time spent on infrastructure would be time not spent on product.

The second sells to consumers and to trade, with contract pricing per stockist, minimum order quantities on wholesale, and an existing WordPress site that generates substantial organic traffic. They employ a developer.

WooCommerce. The trade requirements would force Shopify Plus, the content site is already the traffic engine, and they have somebody to own maintenance. Same sector, same size, opposite answer.

The variable was never the size of the business. It was the checkout requirements and the maintenance capacity, which is exactly what the questions above are designed to surface.

A note on switching costs

Worth factoring in before treating this as a clean comparison: if you already have a store, the cost of the decision includes moving.

Migration is not only data transfer. It is rebuilding integrations, recreating transactional emails, mapping every URL, retraining whoever runs the store daily, and accepting a period of reduced performance while search engines reassess. Detail in migrating without losing search traffic.

That cost is real enough that “the other platform is slightly better for us” is usually not sufficient reason to move. The threshold for switching should be higher than the threshold for choosing, and we routinely advise businesses to stay where they are.

Questions to ask any agency recommending one

If you are taking advice on this decision, these questions separate a considered recommendation from a default one.

“Which do you build on?” An agency that only builds on one will recommend that one. That does not make them dishonest, but it does mean the recommendation carries less information than it appears to.

“What would make you recommend the other?” A good answer names specific conditions. A vague answer means the decision was made before they heard your requirements.

“What does my checkout need to do?” If they have not asked this, they have not made a platform decision — they have made a platform assumption.

“Who will maintain this in two years?” An agency that does not raise this on a WooCommerce recommendation is not thinking past launch.

“What happens if I want to leave?” Both platforms allow it. The answer should be a description of the process, not discomfort.

Ownership, in practical terms

“Data ownership” gets used loosely, so here is what it actually means day to day.

On WooCommerce you hold the database. You can query it directly, back it up whenever you like, move it to another host, and build anything you want against it. If your business needs to do something unusual with its own order data, nothing stands in the way.

On Shopify you have export tools and APIs, which cover the overwhelming majority of real needs. What you do not have is the underlying store. Historical order data is harder to extract completely, and you are working within the surface the platform exposes.

For most businesses this distinction is theoretical and Shopify’s exports are entirely sufficient. It becomes concrete in two situations: when you have contractual or regulatory obligations about data custody, and when you eventually want to leave.

Neither position is wrong. It is worth knowing which one you are choosing rather than discovering it later.

Where to go next

If you have landed on Shopify, our Shopify development service covers custom themes, headless builds and migrations. If WooCommerce is the fit, our WooCommerce work starts with an infrastructure audit rather than a quote.

Still unsure? Tell us what you are building and we will give you a straight answer, including if that answer is that you do not need us.

Build eCommerce Websites Blog

Building a support assistant that quotes your real policies

The failure that makes this risky

Grounding, in plain terms

Scope: what an assistant should and should not answer

Order status deserves its own paragraph

The refusal path is the product

What the logs are actually for

Testing it before customers do

Where automation genuinely helps here

What we build, and what we decline to build

Category and search pages: the funnel nobody audits

Why this part of the funnel gets skipped

Search users are the audience you are ignoring

The zero-results page is the most expensive page you own

Filters: build from questions, not from your database

Faceted navigation and the URL explosion

Pagination that works for people and crawlers

The audit we run, in order

Accessibility is not a separate pass

What we would change first

Ecommerce Core Web Vitals: what actually moves the numbers

The three metrics, and what each one means on a store

Field data is the only measurement that counts

LCP: it is the image, and it is the first one

INP: the apps are doing it

CLS: reserve the space

What to do first, and what it costs

The honest case for doing this

Measuring your own store this week

Shopify theme or custom build: how to decide

What the three options actually are

The question that decides it

When a premade theme is the right answer

When customising is the right answer

When a custom build is genuinely cheaper

What a custom build actually costs to own

What you should build custom regardless of route

How we advise clients

Starting with a theme is not starting badly

Choosing WooCommerce hosting that actually works

Why WooCommerce is harder to host than a website

The four things worth asking about

PHP workers, and why “unlimited” is not an answer

Object caching is the single biggest lever

The database is the part nobody looks at

Who patches what

Staging is a hosting feature

What we specify on client projects

How to test a host before you commit

Migrating without breaking things

Agency, freelancer or in-house: how to staff ecommerce work

The three options, honestly

Freelancer

In-house

Agency

The comparison

When you should not hire us

When an agency genuinely earns the difference

A hybrid that works well

How we structure it

How to evaluate whichever you choose

Setting the arrangement up to work

The uncomfortable summary

How to migrate ecommerce platforms without losing search traffic

Export before you can’t

Build the redirect map

What breaks on every migration

URL structure

Customer passwords

Also plan for

Test the redirects

Launch and afterwards

If you skip the export

A realistic timeline

What to tell stakeholders beforehand

AI product descriptions that don't damage accuracy

The failure mode

Feed specifications, not names

Build review into the workflow