---
title: "Build vs Buy: A Recommendation Engine for Publishers, Both Costs"
description: "Build vs buy a publisher recommendation engine, both costs printed: 18 to 24 months and a standing ML team, or eight weeks to a measured +46% in sessions."
url: https://preview.artificialpoets.com/solutions/recommendation-engine/
site: Artificial Poets
type: page
date: 2026-08-09T06:31:06+00:00
modified: 2026-08-18T02:30:18+00:00
---
# Build It in Eighteen Months. Buy It Running in Eight Weeks.

**Measured on live deployments · Both paths priced**

"Our engineers say they could build this in a year. Are they wrong?" About the code, probably not. About the calendar and the payroll, yes: a first production ship runs 18 to 24 months, and the retraining, monitoring and MLOps never stop. Buying it is eight weeks to an effect you can measure, +46% multi-page sessions on enabled titles while comparable titles fell 16%.

[See it on my numbers](/request-a-demo/) · [Get the pilot design template](/resources/pilot-design-template/)

Horse & Rider · Ride TV · Equine Network · Equus Magazine · The Score · Equine Network Lockup

## What building it costs, before it ships

Nobody in this argument disputes that recommendation works. Netflix put about 80% of viewing on it and valued the retention near $1B a year (Gomez-Uribe & Hunt). The question is what it costs a publisher to own that capability outright, and that is a payroll question rather than an engineering one. The figures below are estimates from public salary data, printed as estimates.

- **~$500k / year** Salary alone for the smallest team that can run this: an ML engineer, a data engineer, and someone who owns MLOps. US medians, 2026 (Levels.fyi, Glassdoor), before benefits, recruiters or infrastructure
- **3–4 months** Before a new ML hire ships anything, on top of however long the search takes. Specialist hiring is the constraint most build plans price at zero
- **Never zero** The bill after launch. Retraining, drift monitoring and pipeline upkeep are permanent roles, not a project phase. A model nobody retrains quietly stops working, and nothing alerts you

## Build, or buy. On one clock.

Time to a working engine, drawn on one scale. The build bar is an estimate and it is drawn generously: 18 months is the optimistic end of the range, and it assumes the hires land. The eight weeks is how our deployments actually run.

- **18–24 months** Build in house, to a first production ship. ML, data and MLOps roles hired and retained before anything reaches a reader, then the operations bill above, permanently
- **8 weeks** Buy it. Authorization to an effect you can measure in your own analytics, run and tuned by our team
- **4 + 4 weeks** What the eight weeks are: four of measurement only while the engine indexes your archive, then four of serving and tuning from a named enablement day

## What the eight weeks buys

Build vs buy

Every line here is either a cost the build carries and the deployment does not, or a control publishers assume they hand over when they buy, and do not.

- **A calendar you can commit to** — Eight weeks from authorization, with the enablement date picked by you. Nothing about it waits on a hiring market.
- **No standing ML payroll** — Retraining, drift monitoring, pipeline upkeep and on-call are our job. You do not carry three specialist salaries to keep one system alive.
- **Evidence before you commit, not after** — A build has no numbers until it ships. This one already has nine months of them, against a comparison group, with the pause test printed.
- **Editorial control stays with editors** — Pin, exclude and constrain what the system may serve. Selection runs inside your rules, and the optimization target is voluntary continuation rather than click-through.
- **Your data and your content stay yours** — Anonymous reader profiles, no PII stored, nothing pooled across customers or resold. The measurement record lives in your own analytics.
- **Your engineers stay on your product** — The strongest argument against building is not the price. It is that twelve months spent on a recommender is twelve months not spent on the thing only your team can build.

**Introducing**

## Artificial Poets Platform

One engine behind every solution on this site. It learns your archive and your readers, then acts inside your CMS, your templates and your ad stack.

- It learns your archive: **Every story you have published, current again** — The engine understands each piece by what it is about, not when it ran or where it was filed. A feature from 2019 competes for the next slot on merit with one from this morning.
- It reads the visit: **What a reader wants, without asking** — Interest builds from what someone actually does in the session. No login, no third-party cookies, nothing leaving your domain. Useful on the second pageview, not the tenth visit.
- It chooses: **The right next read, not the popular one** — Someone comparing products and someone following a running story want different things. A most-read list gives both the same five links and serves neither.
- It serves: **There before the reader leaves** — The feed, the recommendations, the search answer and the signup ask all run on the same engine, in your templates and your ad stack. Any slot that arrives with them is yours to sell.
- It proves: **A lift you can defend, or we say so** — Every deployment runs beside titles that did not get it, plus a serving pause. That is how a result becomes a number you can take to a board instead of a vendor claim.

## The evidence, at its honest tier

- **The baseline is frozen before anything is served** — Four weeks of measurement only, then enablement on a named day. The comparison is against your own numbers from before, not against a model of them.
- **Multi-page sessions** — +46% on enabled titles (10.3% to 15.1%) vs −16% on comparison titles (12.0% to 10.1%), over nine months
- **Largest single-title lift** — +19.1% in the first quarter, +4.0% at steady state. Both published; plan on the second
- **Median engaged session** — Gained about 50 seconds of reading, roughly 30 seconds per served article
- **Verified three ways** — A comparison group (the entire eligible set), a window-sensitivity sweep, and a four-week pause in serving that returned the metric to baseline and recovered on resume
- **Traffic did not grow** — Sessions and users were flat. This is a depth result, and we say so

## FAQ

### Our engineers say they could build this. Could they?

Probably, yes. Capability is rarely the blocker. The blocker is that a first production ship runs 18 to 24 months, needs ML, data and MLOps roles hired and retained before a single reader sees anything, and then needs those roles permanently for retraining and monitoring. The build estimate on this page is drawn at the optimistic end of that range on purpose.

### What does building it actually cost?

Salary is the floor: about $500,000 a year at 2026 US medians for the smallest viable team of three, before benefits, recruiters or infrastructure. Add three to four months before a new ML hire ships anything, on top of the search. Then add the part most build plans price at zero, which is the permanent operations bill after launch. The honest comparison is not build cost against licence cost. It is a standing team against a deployment.

### What do we give up by buying?

Less than the usual answer. Editors pin, exclude and constrain what the system may serve, and selection runs inside those rules. The optimization target is printed: voluntary continuation, not click-through. What you do give up is the ability to change the core ranking yourself, and deeper tuning is run with our team. That is the trade, and it is the point of buying.

### We've been burned by recommendation widgets before. How is this different from the chumbox networks?

Those networks are arbitrage: they rent your page to send readers somewhere else, and the pennies came with a trust cost. The Platform serves only your own library, on your own domain, and is measured on whether readers voluntarily continue. Continuation past the fourth served article runs 70 to 82%, with a 19-second per-article reading floor. A widget chasing clicks does not produce that curve.

### Your models are trained on our first-party data. What do we keep when the contract ends?

Your behavioural data and your content stay yours; we do not pool them across customers or resell them. Reader profiles are anonymous, with no PII stored. Every measurement report we produce is delivered to you and stays yours. The disposition of derived models and embeddings is a contract term, and we put it in writing rather than in web copy.

### Adtech is consolidating. Will you exist in three years?

A fair question to ask of anything you buy instead of build, so the risk is priced into the design: the integration is a JavaScript tag with nothing to unpick, your behavioural data and your content stay yours, and the measured record lives in your own analytics. Whatever happens to any vendor, including us, what you keep is yours.

### How do we explain this to the newsroom?

With one sentence: it ranks, it never writes. It serves only your own library, in your templates, under editors' pin and exclude controls; it stores no PII and nothing leaves your domain. And every claim about it comes with a comparison group your analysts can check.

## Related

- [You Can’t Get the Traffic Back. You Can Get the Session Back.](https://preview.artificialpoets.com/resources/traffic-back/) — The economics of session depth, and the causal evidence behind it: +53% pageviews per user, 95% CI [+48%, +58%], with the modelling assumptions written down.
- [Horse & Rider Grew Pages Per Session 19% Without Growing Traffic](https://preview.artificialpoets.com/customers/horse-and-rider/) — In the first quarter after enabling the Platform, one in six Horse & Rider readers went past the first page, up from one in ten. Three comparable titles moved less than a quarter of a point.
- [Make Every Vendor Wait Four Weeks](https://preview.artificialpoets.com/blog/four-week-baseline/) — Before any vendor's feature turns on, their instrumentation should run for four weeks doing nothing but measuring. It is the cheapest demand you can add to a contract, it converts the eventual results from arguable to checkable, and the way a vendor reacts to being asked is itself the best free diligence you will run this year.
- [Make Every Visit Worth More](https://preview.artificialpoets.com/solutions/session-depth/) — "Traffic keeps falling and I can't stop it — how do I make the visits I still get worth more?"

## See how this works on your titles

Thirty minutes on your analytics. We tell you what share of your sessions stop at the first page, and what this would realistically move first for a setup like yours. You leave with the annotated read. No deck.

[See it on my numbers](/request-a-demo/)

How these numbers are made: [the measurement method](/solutions/measurement/). Platform figures from a multi-title publisher network measured continuously, August 2025 to May 2026. Build-side figures are estimates from public 2026 US salary data (Levels.fyi, Glassdoor), printed as estimates. Last updated August 17, 2026.

## Questions this page answers

### Should we build or buy a recommendation engine?

Buy it unless the recommender is the product you sell. A first in-house production ship runs 18 to 24 months and needs ML, data and MLOps roles hired and retained before a reader sees anything, then permanently for retraining and monitoring. A deployment runs eight weeks from authorization: four weeks of measurement-only baseline, then four of serving and tuning, run by our team.

### What does it cost to build a recommendation engine in house?

Salary is the floor. The smallest viable team is three people, an ML engineer, a data engineer and someone who owns MLOps, which is roughly $500,000 a year at 2026 US medians before benefits, recruiters or infrastructure. Budget three to four months before a new ML hire ships anything, and treat retraining, drift monitoring and pipeline upkeep as permanent roles rather than a project phase.

### How long does buying one take instead?

Eight weeks from authorization on the Platform. Four weeks are measurement only while the engine indexes the archive and the baseline is frozen, then enablement on a day you pick, then four weeks of serving and tuning. The effect is measurable at week eight in your own analytics against that frozen baseline.

### What do you give up by buying rather than building?

The ability to change the core ranking yourself; deeper tuning is run with our team. Everything publishers usually fear losing stays: editors pin, exclude and constrain what the system may serve, selection runs inside those rules, the optimization target is voluntary continuation rather than click-through, and your behavioural data and content stay yours and are never pooled across customers.

### Does a bought recommendation engine actually work on publisher titles?

On the measured network, multi-page sessions rose 46% on enabled titles (10.3% to 15.1%) while comparison titles fell 16% (12.0% to 10.1%) over nine months. Verified three ways: a comparison group of the entire eligible set, a window-sensitivity sweep, and a four-week pause in serving that returned the metric to baseline and recovered on resume. Sessions and users were flat, so this is a depth result and we say so.

### How is this different from Taboola-style widgets?

Those networks rent your page to send readers somewhere else, and the pennies come with a trust cost. The Platform serves only your own library on your own domain, is measured on voluntary continuation rather than click-through, and your behavioural data stays yours. Editors can pin, exclude, and constrain what it may serve.