Why do you start with a best-sellers baseline instead of a real model?

Because it is uncomfortably good and it takes a day. Best-sellers within the same category, shown in the right place, beat a great many personalised systems on a mid-size catalogue. It also becomes the thing every later version has to beat. If the sophisticated model cannot outperform that baseline in a test, the honest conclusion is that the baseline stays and you keep the rest of the budget.

We have no browsing data, only orders. Is that enough?

It is enough for similar-items and frequently-bought-together, which are usually the two highest-earning placements anyway. It is not enough for genuine personalisation, because personalisation needs to know what someone looked at and abandoned, not only what they bought. If personalisation is the goal, event tracking has to go in first and then collect for a while, and that is a phase in its own right.

Should we just install a recommendations app from our platform instead?

Sometimes, yes, and we will say so. On Shopify and WooCommerce there are apps that cover the standard placements for a small monthly fee. When that is the sensible answer, the work becomes configuring it properly, wiring the business rules, and running the test that tells you whether it is doing anything — which is the part almost nobody does.

How long does the A/B test need to run?

Long enough for the result to mean something, which depends on your traffic and order volume rather than on a calendar. We calculate the required sample before switching it on, and we agree the stopping rule at the same time. Reading a test early because it looks good on day three is how a random fluctuation gets deployed permanently.

What stops it recommending things we do not want to sell?

A rules layer that sits between the model and the page. It suppresses out-of-stock items, the product already in the basket, near-duplicates of the item being viewed, and anything outside a sensible price band relative to what the customer is looking at. Those rules are written with you, because some of them are commercial decisions rather than technical ones.

Does this slow the site down?

It should not. For most catalogues recommendations are computed in advance and read from a table at page render, which costs milliseconds. Live computation is only worth its complexity when the suggestions genuinely need to react within a session, and we will tell you when your case does not require it.

AI & Machine Learning

Recommendations you can prove earned their keep

Similar items, you-may-also-like and basket suggestions — built simplest thing first, then tested against what you already show.

From: $3,000–$25,000
Typical time: 6–14 weeks
Usually bought by: E-commerce, media

What this actually solves

Most catalogues are shaped like a funnel with the sides missing. A visitor arrives on one product page from search, decides yes or no about that single item, and leaves. Everything else you sell is invisible to them. The categories in the navigation are how you organise the shop, not how anyone shops, and the search box only helps people who already know the word for what they want.

Recommendations are the mechanism for showing the rest of the catalogue at the only moment someone is paying attention. The two placements that do most of the work are unglamorous — similar items on a product page, and complete-the-set on the basket — and they move basket size rather than traffic, which is why they tend to be the cheapest revenue in the shop to unlock. Nothing new has to be acquired.

The reason this service so often disappoints is not technical. It is that the system gets installed, the site looks more sophisticated, everyone is pleased, and three months later somebody asks what it earned and no one can answer. There was no comparison running, so there is no number. That question arrives at renewal, and an unanswerable question at renewal ends the engagement. The test is therefore not an optional extra at the end of this project. It is the deliverable.

How the work runs

Audit the data and choose the placements. What behavioural data actually exists — orders certainly, views and add-to-cart events far less often — plus catalogue size, category structure, and where suggestions will appear. Two well-chosen placements beat six sprinkled everywhere. Three to five days.
Ship the baseline first. Best-sellers filtered to the same category, live in the real placements. It is simple, it works surprisingly well, and it becomes the control arm that everything after it is measured against. About a week.
Build the similarity layer. Embeddings of product titles, descriptions and attributes, stored in pgvector, giving genuinely related items rather than items that happen to share a category tag. Where order history supports it, a bought-together signal is blended in using the classic collaborative libraries. One to three weeks.
Write the rules and solve cold start. Suppress out-of-stock lines, the item already in the basket, near-identical variants of the product being viewed, and prices wildly out of band. New products and first-time visitors get a defined fallback rather than an empty shelf. Four to eight days.
Deploy behind a split and let it run. Traffic divided between the baseline and the new version through GrowthBook or PostHog, with the sample size and stopping rule agreed in advance and the primary metric named before the switch is flipped. Two to six weeks, depending on your volume.
Read the result and decide. Uplift or no uplift, reported against the control, with the recommendation that follows from it — including the recommendation to keep the baseline if that is what the numbers say. Two to three days.

What moves the price

The range is $3,000–$25,000 over 6–14 weeks, and the timeline includes the test rather than ending at deployment. Three things move the number.

The state of the behavioural data. If order history is clean and complete, work starts immediately. If the goal is personalisation and there is no event tracking, tracking has to be installed and then left to accumulate before modelling can begin — roughly an extra month before anything can be built, and it is the most common reason a quote moves.

Catalogue size and how many placements. A few thousand SKUs behave differently from hundreds of thousands, both in what technique is appropriate and in how much data cleaning sits underneath. And each additional placement is its own logic, its own rules and its own arm of the test, not a copy of the last one.

Whether suggestions must be live. Precomputing recommendations nightly is simple, cheap and sufficient for most shops. Reacting inside a session — adjusting to what someone clicked two minutes ago — needs real-time infrastructure and pushes the build toward the upper half of the range.

What usually goes wrong

It ships without a control group. Recommendations go live everywhere at once, sales drift up slightly over the same period that a campaign ran and the season changed, and nobody can separate the three. The fix costs nothing at the start and is impossible afterwards: hold back a slice of traffic from day one, even a plain fifty-fifty split, so there is something to compare against.

The rules layer is treated as polish. Without it the system will confidently recommend the sold-out colourway, the item already sitting in the basket, and the same three best-sellers on every page in the shop. Each of those is individually small and collectively makes the feature look broken, which is how a working model gets switched off.

Collaborative filtering is chosen before there is behaviour to collaborate on. The technique needs many users interacting with many items. Applied to twelve months of orders on a modest catalogue it produces sparse, unstable suggestions that change wildly on one new purchase. Content-based similarity from embeddings is the right tool at that scale, and the collaborative version earns its place later, when the data volume actually supports it.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Why do you start with a best-sellers baseline instead of a real model?: Because it is uncomfortably good and it takes a day. Best-sellers within the same category, shown in the right place, beat a great many personalised systems on a mid-size catalogue. It also becomes the thing every later version has to beat. If the sophisticated model cannot outperform that baseline in a test, the honest conclusion is that the baseline stays and you keep the rest of the budget.
We have no browsing data, only orders. Is that enough?: It is enough for similar-items and frequently-bought-together, which are usually the two highest-earning placements anyway. It is not enough for genuine personalisation, because personalisation needs to know what someone looked at and abandoned, not only what they bought. If personalisation is the goal, event tracking has to go in first and then collect for a while, and that is a phase in its own right.
Should we just install a recommendations app from our platform instead?: Sometimes, yes, and we will say so. On Shopify and WooCommerce there are apps that cover the standard placements for a small monthly fee. When that is the sensible answer, the work becomes configuring it properly, wiring the business rules, and running the test that tells you whether it is doing anything — which is the part almost nobody does.
How long does the A/B test need to run?: Long enough for the result to mean something, which depends on your traffic and order volume rather than on a calendar. We calculate the required sample before switching it on, and we agree the stopping rule at the same time. Reading a test early because it looks good on day three is how a random fluctuation gets deployed permanently.
What stops it recommending things we do not want to sell?: A rules layer that sits between the model and the page. It suppresses out-of-stock items, the product already in the basket, near-duplicates of the item being viewed, and anything outside a sensible price band relative to what the customer is looking at. Those rules are written with you, because some of them are commercial decisions rather than technical ones.
Does this slow the site down?: It should not. For most catalogues recommendations are computed in advance and read from a table at page render, which costs milliseconds. Live computation is only worth its complexity when the suggestions genuinely need to react within a session, and we will tell you when your case does not require it.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Recommendation engine All AI & Machine Learning services