How long does recommendation engine development take? A realistic timeline

Recommendation engine development takes six to eight weeks for a first surface when a usable event stream already exists, ten to fourteen weeks for a production programme across two or three surfaces, and fourteen to twenty weeks for a multi-surface platform with real-time features. Add four to eight weeks after launch before the result is readable.

Those are delivery weeks, not calendar guesses. Below is the schedule we actually run, which workstreams overlap, the six conditions that add weeks, and why the honest answer to "when will we know if it worked" is always later than the launch date.

The critical path is data, not modelling

Ranking code is not the long pole. On most engagements the longest single stretch is getting a trustworthy event stream: views, clicks, cart events and purchases carrying stable user and item identifiers, on every surface including the mobile app. Teams assume this exists because they have analytics. Analytics tags are built to count sessions, and they very often drop the item identifier that a recommender needs, which is why an audit in week one saves an argument in week six.

The second long pole is access. Catalogue data, stock levels, order history and the placement in the front-end each belong to a different team, and each needs a named person with time allocated. A programme with one decision maker on your side who can unblock all four moves roughly two weeks faster than one where each request queues separately.

The third is the measurement window, which is fixed by your purchase cycle rather than by engineering. A grocery business reads a result in two weeks; a furniture business needs two months. No amount of delivery speed shortens it, so plan the readout date at the start and work back. The reasoning is set out in personalisation lift.

A week-by-week schedule for a first surface

This is the six-to-eight-week shape for one placement over an existing clickstream. Each row names what you get and who we need from your side.

Weeks are elapsed, not effort. A team of three runs this comfortably; adding people to the pipeline phase does not compress it, because the constraint is your release schedule for instrumentation rather than our capacity.

What can run in parallel

Three overlaps are safe and we use all of them. Candidate generation can be built against backfilled order history while live instrumentation is still shipping, because purchases are the highest-quality signal and you already own them. Front-end placement work can start as soon as the response contract is agreed, using a stubbed endpoint, which removes the front-end team from the critical path entirely. And the experiment harness, holdout assignment and dashboards can be built during the modelling weeks rather than after, which is what stops measurement being the thing that slips.

One thing must not be parallelised: business rules cannot be agreed after launch. If the merchandising team has not settled what may never be recommended, the rollout stalls at the last gate with an audience waiting.

Who is on the team matters less than who is available. A first-surface build needs a data engineer, a machine learning engineer and a product owner from us, and from you a front-end engineer for the placement, an analytics owner for instrumentation and one commercial decision maker. About half our personalisation work is paired with an internal team, with documented handover at the end, and the paired shape runs at the same pace provided the internal engineers have protected time rather than spare time. A part-time contributor on the critical path is the quietest way to lose a fortnight.

What adds weeks

Six conditions account for nearly every overrun we have seen.

• No item identifiers in mobile events. Adds three to five weeks, because it needs an app release and then time to accumulate data through the store review cycle.
• Logged-out to logged-in identity stitching. Adds two to four weeks and is a genuine engineering project, not a configuration setting.
• Catalogue remediation. Duplicate SKUs, missing attributes and inconsistent categories add one to three weeks, and the work sits with people who know the products rather than with engineers.
• Real-time ranking instead of batch. Adds three to six weeks for a feature store, an online serving tier and the operational cover they need.
• A second or third surface. Roughly 60 per cent of the first surface for the second, less thereafter, because context, latency budget and rules differ per placement.
• Unagreed objective. The slowest programmes are the ones where nobody has decided whether the system optimises revenue, margin or stock clearance. That is a commercial decision and it should be made in week one.

Recommendation engine development delivery time by scope

One surface, batch scoring, existing clickstream: six to eight weeks, from $21,000 or ₹13,60,000. Two or three surfaces with session-aware ranking, cold-start handling and a proper experiment harness: ten to fourteen weeks. Web, app, email and messaging with real-time features and merchandiser-editable rules: fourteen to twenty weeks, up to $70,000 or ₹46,40,000. These are the published personalization engines tiers, and the figures behind each sit on the pricing page rather than being quoted per project.

We run these fixed price and fixed date on a locked scope. That works because the scope is locked before the clock starts, a discipline described in scope lock. Where the surface list or the event picture is still unclear, a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, produces the audit and a date we will commit to. A three-week ProofRun at $6,250 or ₹4,00,000 goes further and proves the hardest surface first.

Why the calendar is longer than the build

Launch day is not the finish line, and treating it as one is how programmes get declared successful before anything is known. After the ramp you need one full purchase cycle of holdout data, a guardrail review, and usually one iteration on rules and diversity. Realistically, the gap between kick-off and a defensible statement about lift is three to five months for a first surface, of which six to eight weeks is engineering.

Plan the operating rhythm now too. Catalogues turn over, seasons shift and rankers decay, so a weekly readout and a retraining cadence are part of the schedule rather than an afterthought. A Care Plan from $1,000 or ₹68,000 a month covers that cover, with the AI add-on at $750 or ₹40,000 for evaluation runs and re-indexing.

When a fast timeline is the wrong goal

If the pressure is to have something live before a peak season, resist shipping a ranker into your busiest weeks. Peak traffic is exactly when an untested change is most expensive and least readable, because seasonal behaviour swamps the effect you are trying to measure. Ship before the season starts or after it ends, never during.

And if the honest answer is that your traffic is too thin to produce a readable result in any reasonable window, the timeline question is the wrong one. You are not choosing between eight weeks and fourteen; you are choosing whether to spend at all. Curated merchandising, better search and a cleaner catalogue will beat a learned ranker on a low-traffic surface, and we will say so.

Keeping the schedule honest

Use a durable event log rather than a fire-and-forget queue, so that a mistake in feature logic costs a replay rather than another month of data collection. Apache Kafka's documentation on retention and replay describes the property that matters: consumers can re-read history from an offset, which is what turns a modelling error into an afternoon instead of a quarter. Getting this right in week two is the cheapest schedule insurance in the programme.

Related reading

Recommendation engine development: a practical implementation guide covers what happens inside each phase, recommendation engine development cost in 2026 attaches numbers to each tier, and event pipelines explains why the first three weeks decide the rest. If you want a date rather than a range, send us the surface and the event picture.

Six to eight weeks buys you a live recommender; three to five months buys you proof it worked, and only the second number belongs in a board update.