Recommendations built from what people actually buy,
not a guess at what they might like
A recommendation engine is only as good as the data discipline behind it: no out-of-stock suggestions, no irrelevant cross-sells, no recommending the item someone just returned. We build that discipline in from the start, on top of your real purchase data.
What it is and who needs it
A recommendation engine suggests products or content based on real behavior, what similar customers bought, what pairs well with what is already in a cart, rather than a fixed cross-sell list someone configured once and forgot. It fits any store or platform with enough catalogue depth and purchase history that manual merchandising cannot keep up. It is not worth building for a catalogue of a dozen items; the value shows up once there is enough data and enough products that a human cannot track every pattern by hand.
What is inside
The model trains on your actual purchase and browsing history, collaborative filtering, embeddings, or a hybrid depending on catalogue size and how much history you have. Stock and relevance guards sit between the model and what actually gets shown, filtering out anything currently unavailable or clearly irrelevant before a recommendation reaches a customer. Placements are built to be tested against each other, product page, cart, email, a chat agent’s upsell, so you can measure what actually lifts basket size rather than assuming. Cold-start logic covers new products and new customers with no history yet, falling back to category or popularity-based suggestions until real behavior data accumulates.
How we build it
We start with an audit of what purchase and browsing data you actually have and in what shape, since model quality depends entirely on that foundation. The model gets trained and validated against a holdout period of real data before going anywhere near a live placement, checking that it beats a simple baseline before we call it done. Stock and relevance guards get built and tested with deliberately broken inventory data, discontinued items, zero-stock edge cases, before launch. We launch on one placement first, measure lift against a no-recommendation control group, and expand to additional placements once the lift is real and measured, not assumed.
What to watch
The risk most teams underestimate is a model that looks good in testing but reinforces its own narrow suggestions in production, a feedback loop where customers only see, and therefore only buy, what the model already recommended. This is why measuring real lift against a genuine no-recommendation control group matters more than trusting an offline accuracy score. Stale inventory data is the other practical risk, a model trained on last month’s stock levels will recommend items that are not actually available unless the stock guard checks live inventory at serve time, not just at training time. Retraining on a real schedule avoids slow drift. Watch for seasonal or promotional periods skewing the training data, a model trained mostly on a sale period can over-recommend discounted items once pricing returns to normal, so retraining timing matters as much as frequency.
Timeline and price
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| MVP | from $2,500 | One placement, stock and relevance guards, cold-start handling | 4 to 6 weeks |
| Production | from $6,500 | Multiple placements, A/B testing, scheduled retraining, lift dashboard | 6 to 8 weeks |
| Full control (handover-ready) | from $11,000 | Everything in Production, plus a full handover package: architecture docs, test suite, admin access audit, and a walkthrough so your own team or another vendor can run it without us | 8 to 9 weeks |
Running cost on top of the build is usually $20 to $70 a month in hosting and retraining compute, depending on catalogue and traffic size.
What you own at the end
You own the trained model, the recommendation pipeline, the guard logic and the full source code, running on your own infrastructure. Retraining schedules and data requirements are documented so your own team can keep the model current without depending on us indefinitely.
Related
Pairs with AI pricing engine since pricing and recommendations both draw from the same catalogue and behavior data, and AI for marketplaces for the broader marketplace automation picture. See the e-commerce service page for store-side builds and the analytics service page for the data foundation underneath this. Real builds: the digital goods marketplace automation case study and the marketplace engine with an AI trend advisor case study. Still running cross-sells off a list someone built a year ago? Get in touch.
FAQ
How much does a recommendation engine cost?
From $2,500 for a single placement (product page or cart) using your existing purchase data. A build covering multiple placements with A/B testing and scheduled retraining runs $6,500 to $11,000.
How long does it take?
Four to six weeks once you have at least a few months of purchase or browsing history to train against. Catalogues without much history yet start with rule-based recommendations and transition to learned ones as data accumulates.
What is the stack?
Python for the model (collaborative filtering, embeddings, or a hybrid depending on your catalogue size), PostgreSQL or a vector store for similarity lookups, and an API your site, app or chat agent calls to fetch recommendations.
Who owns the model and the data?
You. The trained model, the recommendation logic and the underlying data pipeline run on your own infrastructure, with no dependency on a recommendation SaaS charging per request indefinitely.
How do you stop it from recommending something out of stock?
A stock guard checks live inventory before a recommendation is served, not just at training time. An item that goes out of stock between retraining cycles gets filtered at serve time, not recommended anyway.