Site search RFP questions for self-hosted search

Site search RFP questions: how to run the evaluation

A team that must replace or add site search needs every self-hosted option and every implementation partner measured on equal terms, and the request for proposal (RFP) is the instrument that makes that possible. The RFP should test six things: platform and edition fit, licence obligations, migration of existing data, hosting model, security evidence, and post-go-live support, with the fixed scope defined in writing before any price is compared. The same question set goes to every bidder, and every answer must be written, signed and dated so that claims can be checked later against the contract.

A vendor-neutral brief is the safer starting point because it describes the outcome (query volume, catalog or content size, tenancy, data location, uptime target, accessibility needs) without naming an engine. Asking bidders to justify a choice among Meilisearch, Typesense and OpenSearch keeps the evaluation open until the requirements are known. Ask each bidder to state which engine and edition they propose, which licence terms apply to that edition, and which capabilities are missing compared with the hosted service you use today. Ask for a written statement on each gap, not a general claim of parity.

Confirm the answers against your own environment before scoring. Where a bidder cites a version, check it against the vendor's current release page on the day of evaluation, because release lines and maintenance windows change. Score written answers, request a reference architecture and a sample runbook, and mark any answer that is verbal, conditional or deferred to a later statement of work as unanswered. A structured comparison of this kind shows which proposals are complete and which are only promising.

Which questions test platform and edition fit

Meilisearch's Community Edition is published under the MIT license, while its Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement. The RFP should force the vendor or partner to state which edition each feature depends on, because multi-tenancy and replication claims often sit in different editions. Ask how the README's multi-tenancy feature, which personalizes results for any number of application tenants, is delivered in the edition you plan to run.

Edition boundary: Which features in your requirement list are available in Community Edition, and which need a commercial agreement? Ask for the written position on production use.
Typo tolerance and faceting: Ask the partner to demonstrate typo tolerance and filtering on a sample of your catalog, including how filterable and sortable attributes are declared.
Hybrid search: Confirm which embedder options are supported, where embeddings are generated, and whether that step runs inside your environment.
Algolia gaps: If you are migrating, ask for the mapping of attributesForFaceting and sort replicas, and how aroundPrecision, restrictHighlightAndSnippetArrays and disablePrefixOnAttributes will be handled, since the migration guide states they have no equivalent.
Front-end adapter: Confirm whether InstantSearch front ends will use the Instant Meilisearch adapter and who makes the changes.

Check that the vendor's answers match the current release on the Meilisearch GitHub releases page at the time of the RFP.

Questions to ask by area, with what a good answer contains

Which licence applies to each engine and what must we comply with?

The answer should name the exact licence file for every component you will run, and say which obligations apply to your internal use. Meilisearch Community Edition is MIT licensed, while its Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement. Typesense server is GPL-3.0 with Apache-licensed clients, and the bidder should explain what changes if you modify the server code. OpenSearch is Apache License 2.0 and its FAQ describes no paid edition. Ask the bidder to list every plugin, extension and model file, since each may carry its own terms and should be checked against your legal team's requirements.

How will existing search data be migrated from Algolia or another engine?

A credible answer lists versioned migration steps with the export method, the import method, and the field mapping. For Meilisearch, the bidder should name the Algolia export with browseObjects and the import with addDocumentsInBatches in batches of 100,000, along with the mapping of attributesForFaceting to filterableAttributes and sort replicas to sortableAttributes. For Typesense, the answer should cover the Algolia CLI JSONL export, the objectID to id mapping, and the documents import endpoint with action=upsert. Ask which Algolia features have no equivalent, such as aroundPrecision and disablePrefixOnAttributes for Meilisearch, and how the bidder will test relevance after cutover.

What does the hosting model look like, and where does query and index data live?

The bidder should provide a written hosting diagram that shows where each node, backup and log store runs, and which network zones can reach them. Ask whether the engine runs in your cloud account, your data center or an air-gapped network, and who holds the operating credentials. For Typesense, the answer should name the highly available cluster size, such as a 3-node or 5-node Raft cluster, and the memory sizing, including keyword RAM of roughly 2 to 3 times the searchable field size. Confirm where query logs are stored, since they can contain personal data, and how that storage is covered by your retention policy.

What security evidence can the bidder show before go-live?

The bidder should show evidence you can review, not a general statement of security. For OpenSearch, the answer should name the Security plugin features in use: authentication through SAML, OpenID Connect, LDAP or Active Directory, role-based access control, document-level and field-level security, field masking, audit logs and TLS for node and client traffic. Ask for the hardening baseline, the configuration files that enforce it, and the results of security testing against the search API and admin interfaces. Confirm which evidence DeployOpen prepares and which an independent assessor must issue, since DeployOpen does not issue audit reports or certifications.

What support, upgrades and fixes apply after go-live?

A good answer separates the one-time work from the recurring work and states the support window for each version. For OpenSearch, ask how the bidder will track the minor release cadence and the maintenance rule, under which a version stays in maintenance until the next major version enters maintenance or one year passes, whichever is longer. Ask who applies security patches, who tests them against your catalog, and who handles backups and snapshots. Recurring support is usually sold as a retainer, so ask for the response process, the upgrade test plan and the exclusions, and confirm that the bidder will document each change in your runbook.

How is the fixed scope defined, and what is excluded?

Most engagements are fixed scope, and the written scope should be the basis of the quote. Ask for a scope document that lists deliverables, acceptance tests, environments, data volumes, integrations and the responsibilities of your team. Good answers name specific acceptance criteria, such as a successful full reindex, search result checks on a agreed query set, and a tested rollback. Ask which items are excluded, such as relevance tuning beyond the agreed set, custom front-end work, or model hosting for semantic search, and how change requests are priced. Cost drivers include catalog size, number of tenants, integrations and the number of environments, so ask for a quote that shows each driver.

What licence obligations the RFP must surface

Licence questions belong before feature questions because they decide whether the intended deployment is permitted at all, and they are expensive to unwind after a platform is chosen. A bidder can demonstrate typo tolerance or hybrid search in a day, but a licence that does not cover production use can stop a go-live after months of build work. Ask every bidder to name the exact licence and edition for each component in the proposed stack, including the search server, client libraries, admin dashboards and any connectors, and to state which features depend on a paid or separately licensed edition.

Meilisearch shows why the edition split matters. Its Community Edition is MIT licensed and fully open source, while the Enterprise Edition is governed by a commercial license or the Business Source License 1.1 and is not permitted in production without a commercial agreement. The RFP should require the bidder to list every feature in the design that sits in the Enterprise Edition, to name the features that must be avoided, and to confirm in writing whether multi-tenancy or high-availability options used in the design are Community or Enterprise. Typesense is a different case: its server is GPL-3.0 while its client libraries are Apache licensed. The project explains that the GPL lets a company run modified server code internally without publishing changes, as long as it does not distribute that code. Ask the bidder to confirm whether the planned use involves distribution, such as shipping a modified server inside a customer-facing product, and have the vendor or your legal team confirm that the intended use is covered.

OpenSearch is released entirely under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition. That simplifies the licence review, but it does not remove the questions. Ask the bidder to show which OpenSearch plugins, dashboards components and third-party extensions are bundled in the design, and to confirm each one's licence, since a component outside the core project may carry different terms. Record the answers in the contract so that any later change of edition, plugin or vendor triggers a fresh licence review. Your own legal team, not the bidder, should sign off on whether the planned use, internal or distributed, is covered.

Answers that should worry the evaluation team

Vendor and partner answers often sound complete while leaving out the details that decide cost, risk and support after go-live. The cards below describe the answers that should slow an evaluation down, and what to ask for instead.

An unnamed edition

A response that says "Meilisearch" or "OpenSearch" without naming an edition or release leaves open which features, licence and support terms apply. Meilisearch's Community Edition is MIT licensed, while its Enterprise Edition is governed by a commercial licence or the Business Source License 1.1 and is not permitted in production without a commercial agreement. Ask for the exact edition, the exact version and a written list of the features that depend on it.

Production use called free without a licence read

Statements that self-hosting is free often refer to the software price only. The licence text decides whether production use, internal use or hosting for clients is allowed, and whether any modules need a paid agreement. Ask the vendor to name the licence for every component in the proposed stack and to confirm in writing which parts require a commercial contract.

Migration without counts or field mapping

A migration described only as "we will move your data" hides the work that usually causes delays: record counts, field and parameter mapping, and features with no equivalent in the target engine. Ask for the record and index counts, the export and import method, a mapping of every ranking, faceting and merchandising setting, and the list of settings the target engine does not support.

Security evidence given as assurance

Verbal statements about encryption, access control or audit logging cannot be checked during a review. Ask for the configuration that will be deployed, including TLS for node and client traffic, the authentication backend used with the organization's identity provider, role and field-level access rules, and where audit logs are stored and how long they are kept. Ask for these as written artifacts that the security team can test.

Fixed price without written scope

A fixed fee with no defined deliverables, environments or acceptance criteria tends to change through change requests once work starts. Most engagements should be fixed in writing before work begins, with a scope that names the indexes, data sources, environments, integrations and test results that count as done. Ask for that document before comparing totals.

Support described as best effort

Support offered only as "best effort" gives no response expectations for an outage that takes search down on a live site. Ask which support levels are included after go-live, who patches the engine and the operating system, how upgrades and backups are handled, and whether support is a separate retainer. For OpenSearch, ask how the proposed version's maintenance window fits the release cadence.

How to score the responses

This table compares each RFP area against what a complete written answer contains, what to request in writing, and whether the response passes or needs follow-up. Score on the written answers, not on demos, reputation or how confident a salesperson sounds, and mark anything vague as a follow-up until it is documented.

Area	Complete answer contains	Request in writing	Mark: pass or follow-up
Platform fit	Named engine and edition, version in use, and how catalog size, tenancy and query volume were sized	Edition and feature list the bid depends on, sizing assumptions, and the supported version policy	Pass if the edition covers every must-have feature in writing; otherwise follow-up
Licences	Licence name for server and clients, any commercial-only components, and whether production use needs a paid agreement	Licence text or link, list of features behind paid terms, and written confirmation of production use rights	Pass if production use is confirmed in writing with no hidden paid components; otherwise follow-up
Migration	Source export method, field and setting mapping, handling of unsupported parameters, and reindex plan	Mapping table for existing search settings, known gaps, and the test plan with sample records	Pass if every existing feature has a mapped replacement or an agreed workaround; otherwise follow-up
Hosting model	Where the engine runs, who operates updates, backups and scaling, and how cluster nodes are placed	Hosting diagram, node count for production, backup and restore method, and data location statement	Pass if hosting sits in your accounts or data centers with named owners for operations; otherwise follow-up
Security evidence	Authentication options, access control granularity, audit logging, TLS coverage and how keys are issued and rotated	Configuration baseline, sample audit log output, and evidence that supports your assessment controls	Pass if each control is demonstrated in a written configuration or test record; otherwise follow-up
Support after go-live	Response levels, patch cadence for the engine version, and who handles incidents outside business hours	Support terms, supported version window, upgrade plan, and named escalation path	Pass if terms are written with dates and owners; otherwise follow-up
Fixed scope	Deliverables, acceptance criteria, exclusions, change control and dependencies on your team	Written scope with acceptance tests, assumptions list and the process for changes after signature	Pass if every deliverable has an acceptance test and exclusions are listed; otherwise follow-up

What answers reveal about cost and effort

Ask bidders for cost components, not a single number. A total without a breakdown cannot be compared with another bid, and it hides which lines recur after go-live. Ask each bidder to separate one-time work (migrating existing indexes and synonyms, building the indexing pipeline, integrating with the identity provider, hardening and testing) from recurring work (hosting, patching and upgrades, backups, monitoring, support retainers and the staff time your own team spends on search). For self-hosted options, the software license line is often zero, which means the real money sits in the labor and infrastructure lines. Ask for each line to be shown on its own.

Require every bidder to state its assumptions in writing, because the same platform can cost very different amounts depending on the inputs. The main drivers are catalog size and the memory it needs. Typesense's system requirements guide says keyword search typically needs 2 to 3 times the size of the searchable fields in RAM, and each vector needs 7 bytes per dimension, so semantic results add memory on top of keyword indexes. Tenancy model (one index or many), uptime target (a single node or a 3-node or 5-node cluster) and data location also move hosting and staff effort. Ask bidders to state the record count, expected query volume, number of tenants and availability target they priced against, and to say what changes if any of those grow.

DeployOpen does not publish a price list. A quote follows from the written scope, so expect the proposal to name the deliverables, environments, integrations and support period before it names a figure. Vendor-published pricing is a reference point, not a self-hosting cost. Meilisearch's pricing page lists Meilisearch Cloud starting at $20 per month, and Typesense Cloud's pricing page describes dedicated clusters billed by memory and node count with bandwidth charged separately. Those figures show what a managed service charges for its own infrastructure and operations. They do not include your self-hosting infrastructure, the implementation work, or the support you would need to run the platform yourself. Compare each option on the same basis: the total cost of ownership over the period you plan to keep the platform.

How to issue the RFP and compare answers

This sequence turns a vague search wish list into comparable written answers, a tested shortlist and a fixed scope that both sides can hold each other to. Each step produces a document or result you can review before moving on.

Define requirements and catalog facts
Your product, content or operations lead writes down the number of documents or products, how often they change, the number of tenants or sites, the languages, the data locations you must respect and the uptime you need. Security and privacy staff add identity, retention and audit requirements. The step is done when every bidder can be asked the same numbers rather than a general request for speed.
Send the same brief to each bidder
Issue one written brief with identical requirements, sample data description, hosting constraints and evaluation criteria to every shortlisted engine or implementation partner. Ask each bidder to name the platform and edition they propose, so answers can be compared line by line. The step is done when every bidder confirms receipt and names a single point of contact.
Request written answers by a deadline
Require written answers to each question, including licence terms for the edition proposed, migration approach, hosting model and support hours, returned by one deadline you set and publish to all bidders. Ask for named sources for any claim about feature parity or performance. The step is done when every answer is in the same format and gaps are listed for follow-up.
Run a scoped proof of concept on a copy
Agree a fixed, time-boxed test with each shortlisted bidder that indexes a copy of your data, not production records, and runs your real queries, filters and synonym cases. Measure relevance, indexing time, memory use and how the migration of existing settings and rules actually behaves. The step is done when you have a written results sheet that every bidder has seen.
Check references and security evidence
Ask each bidder for references from comparable self-hosted deployments and for the security evidence they can provide, such as hardening guides, access control design, backup and restore records and any independent test reports they hold. Confirm which items are their own material and which are third-party. The step is done when you have spoken to references and filed the evidence against your requirements.
Agree fixed scope with acceptance tests
Convert the chosen answer into a written scope that lists deliverables, the environments and data locations covered, support terms after go-live and the acceptance tests that prove each deliverable works. Confirm how changes are priced and who owns the hosting and licence costs. The step is done when both parties sign the scope and the acceptance tests are agreed in writing.

How DeployOpen scopes, delivers and supports site search

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For site search, that means turning the answers to the questions in this RFP into a written, fixed scope before any work starts.

How we scope

We confirm the search engine and edition fit against your catalog size, tenancy model and data location requirements.
We record licence obligations for the chosen engine, including what the Community or open-source edition permits in production.
We agree in writing which existing data migrates, from which source, and how records are validated before cutover.

How we build

We deploy the chosen engine in your environment, with hosting, identity integration and TLS configured to your security baseline.
We build the indexing pipeline from your content or catalog source, including sync and reindex procedures agreed in the scope.
We test relevance, access controls and failover behavior against the requirements captured in the RFP before handover.

How we hand over

You receive architecture, configuration and runbook documentation covering deployment, backups, upgrades and reindexing.
We provide security evidence items agreed in the scope, such as configuration baselines, access control records and test results.
Handover includes knowledge transfer to your operations team, with support boundaries and responsibilities stated in writing.

How we support

Engagements are fixed-scope, so deliverables, timelines and exclusions are agreed in writing before work begins.
Ongoing support, upgrades and continuous security testing are available as retainers after go-live.
Ask any partner, including DeployOpen, to state the post-go-live response obligations, upgrade cadence and who holds operational access.

Site search RFP questions