What to put in a recommendation engine development RFP
What should a recommendation engine development RFP include?
A recommendation engine development RFP should specify the surfaces, the event data you already have, the metric and holdout design, the latency budget, the cold-start rule, retraining ownership and the data rules. Without those seven, bids price different projects and cannot be compared.
A recommendation engine development RFP should specify seven things: which surfaces you are personalising, what event data exists today, the success metric and how it will be measured, the p95 latency budget, the cold-start rule, who retrains the model after launch, and the data rules that apply. Everything else is detail.
This article gives you the section structure, the wording that makes bids comparable, the acceptance criteria most buyers forget, and the commercial clauses worth arguing about before you sign rather than after.
Why most recommendation engine RFPs produce bids you cannot compare
A typical brief says: we want a recommendation engine for our e-commerce site, please quote. Three vendors reply with three numbers that differ by a factor of five, and the buyer concludes the market is irrational. It is not. One vendor priced a widget on the product page using an off-the-shelf model. One priced four surfaces, an event pipeline rebuild and an experimentation framework. One priced the second thing but assumed your event data is clean.
The variable that moves the price most is not the algorithm. It is the state of your behavioural data and the number of surfaces in scope. An RFP that leaves both undefined is asking vendors to guess, and the cheapest guess wins the beauty contest and then loses the project in change requests.
The fix is to specify the problem precisely enough that two competent vendors would scope roughly the same work. You do not need to specify the solution. Do not tell bidders which model family to use; tell them what the system has to achieve and let them argue for an approach.
Section by section: what to write and what weak briefs say
| RFP section | What to specify | What a weak RFP says |
|---|---|---|
| Surfaces in scope | Named pages and channels, with traffic volume for each | Personalise the site |
| Current event data | Event names, collection method, retention, known gaps | We use Google Analytics |
| Success metric | One primary metric, holdout size, test duration | Improve conversion |
| Latency budget | p95 in milliseconds per surface, measured at the edge | Should be fast |
| Cold start | What a new user and a new SKU must see on day one | Not mentioned |
| Catalogue and guardrails | Item count, churn rate, stock, margin and legal rules | About 10,000 products |
| Retraining and ownership | Cadence, who runs it, rollback path, handover scope | Ongoing support as needed |
| Data rules | Consent basis, residency, retention, deletion handling | Must be compliant |
| Commercials | Fixed price or T and M, milestones, IP ownership, exit | Please provide your rates |
What to disclose about the data you already have
The single most useful page in a recommendation engine development RFP is an honest inventory of your behavioural data. List the events you collect, where they are collected from, whether collection is client-side or server-side, how far back the history goes, and whether anonymous sessions are stitched to accounts after login. Add the known gaps. A bidder who sees that the mobile app stopped sending add-to-cart events in March will price the remediation; a bidder who does not will discover it in week three and raise a change request.
Describe the catalogue in the same spirit: item count, how many new items appear each month, how many are retired, how rich the attribute data is, and whether descriptions and images are consistent enough to embed. Catalogue churn drives the cold-start design, and cold-start design drives a meaningful part of the price.
Finally, say what you cannot share and when. If the vendor will not see production data until a security review completes, that is a six-week dependency and every bidder should be pricing around it rather than discovering it after signature.
How do you write the success criteria?
Write one primary metric and at most two guardrail metrics. The primary metric should be commercial: revenue per session, items per order, qualified activations, watch time. Guardrails stop a vendor optimising the primary metric at the expense of something you care about, typically margin, returns rate or catalogue coverage.
Then specify how it will be measured, because this is where bids diverge silently. State that acceptance is measured against a randomised holdout, give the holdout percentage, and give the minimum test window in full weeks so weekday and weekend behaviour are both covered. A vendor who prices without a holdout is pricing a different, cheaper project.
Offline metrics belong in the RFP too, as a development gate rather than an acceptance gate. Asking bidders which ranked-list metrics they will report, and on what split, tells you quickly who has shipped before; scikit-learn's reference on ranking and model evaluation metrics documents the standard measures, including normalised discounted cumulative gain, that a serious bid will name.
The acceptance criteria buyers usually forget
- Latency under load. The p95 target must hold at peak traffic, not at 3am on a staging environment.
- Cold-start coverage. A stated percentage of catalogue and of new sessions that must receive non-empty, relevant recommendations.
- Guardrail compliance. No out-of-stock, out-of-region, age-restricted or negative-margin items in any slot.
- Reproducibility. The vendor can rebuild the reported result from your data, with the pipeline and the evaluation set handed over.
- Diversity floor. A minimum spread across categories or sellers, so the engine does not collapse onto your top ten items.
- Rollback. A documented switch back to the previous ranking within minutes, tested before go-live.
- Handover. Runbook, retraining instructions, dashboards and a working session with your engineers, not a slide deck.
What to say about budget and what to ask for in return
State a band rather than a number. Eazyware builds personalisation and recommendation engines from $21,000 or ₹13,60,000, with most scoped programmes landing between $21,000 and $70,000, or ₹13,60,000 to ₹46,40,000. A band in that shape tells bidders whether you are asking for one surface or a platform, and filters out the responses that were never going to fit.
Ask every bidder to break the quote into build, event or data remediation, evaluation and experimentation, and post-launch running. Running costs are the line most often omitted: ours sit in Care Plans from $1,000 or ₹68,000 per month, with an AI system add-on at $750 or ₹40,000 covering evals, retraining and cost monitoring. Our full figures are published on the pricing page, which is a reasonable thing to expect from any bidder.
If the scope genuinely is not clear enough to price, say so in the RFP and ask for a paid discovery instead of a speculative fixed price. A ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, produces the event audit, the surface list and the test design that the real RFP then quotes against.
Commercial terms worth writing into the brief
Three clauses matter more than the rest. First, ownership: the code, the pipelines, the trained model artefacts, the feature definitions and the evaluation sets should all be yours, in your repositories and your cloud accounts. Our position on code and IP ownership is that you own everything, including prompts and model choices, and any bidder should be asked to match it in writing.
Second, change control. Personalisation scope grows by surface, and a fixed price only holds if the surface list is fixed. Write the change process into the brief so it is a known mechanism rather than a negotiation under deadline pressure; scope lock is the discipline that makes a fixed date achievable.
Third, exit. If you stop working with the vendor, what do you keep and how long does the handover take? Ask for the answer in the proposal, not in the contract redlines.
One more clause is worth a sentence: the right to run your own evaluation. Ask that you may score the delivered system against a question set or interaction sample you hold back, on your infrastructure, before final acceptance. Vendors who have shipped before will agree immediately, because their number is the same either way.
When an RFP is the wrong instrument
If you have never personalised anything, a competitive RFP will produce a set of confident documents you have no basis to judge. Run a paid discovery or a single-surface proof with one vendor instead, then write the RFP for the platform build with real numbers in it. The three-week ProofRun at $6,250 or ₹4,00,000 exists for exactly this.
An RFP is also the wrong instrument when the honest answer is that your catalogue is too small or your traffic too thin for a learned ranker. Below a few thousand monthly active users, curated merchandising rules usually beat a model and cost a tenth as much. A vendor who will not tell you that is not the vendor you want.
A shape that works
Our personalisation work for a D2C brand started from a brief that named two surfaces, listed the events that existed and the ones that did not, and set a holdout before any modelling was discussed. That is roughly six pages, not sixty, and it produced quotes that could be laid side by side.
Related reading
Recommendation engine development cost in 2026 explains what the bands include, what a fixed-price AI quote should contain covers the line items to demand, and questions to ask a recommendation engine development vendor before you sign covers the conversation after the paperwork.
A good recommendation engine RFP does not describe the algorithm; it describes the constraints tightly enough that every bid is pricing the same problem.
Frequently asked questions
How long should a recommendation engine development RFP be?
▾
Six to ten pages is usually enough. Depth matters more than length: named surfaces with traffic figures, an honest description of your event data, one primary metric with a holdout design, a latency budget and the data rules. Padding the document with generic vendor questions makes bids harder to compare, not easier.
Should the RFP specify which algorithm or model to use?
▾
No. Specify the outcome, the constraints and the acceptance criteria, then let bidders propose an approach and justify it. Prescribing collaborative filtering or a particular vector database in the brief removes the main thing you are buying, which is the vendor's judgement about what fits your data.
What should the RFP ask about running costs?
▾
Ask for a twenty-four month total, broken into inference or compute, storage, retraining effort, experimentation tooling and support hours. Recommendation engines carry ongoing cost because catalogues and behaviour change. A bid that quotes only the build price is quoting half the project and should be asked to complete it.