Survey tool RFP questions: how to run the evaluation
A team that needs a survey or form tool on its own servers usually has to compare options in writing before anyone signs anything. The questions in this section are written to be neutral: they can go to a software vendor, an implementation partner or a hosting provider without favoring one of them. Ask every bidder to answer in writing and tie each answer to a named scope, meaning the specific surveys, respondent groups, hosting location and users that the platform must serve. An answer that does not reference that scope is a sales claim, not evidence. Score each answer on the same scale, record the evidence behind it (documentation, a test instance, a named contract clause) and keep the scores with the notes so that the decision can be explained later to procurement, legal or an auditor.
LimeSurvey Community Edition and Formbricks are useful examples of what to test, not a shortlist. LimeSurvey is a general-purpose questionnaire platform, while Formbricks is oriented toward in-product and website feedback, so the same question about response data or licensing can have very different consequences on each. Confirm the current licence terms, supported database versions and feature availability directly with the publisher, because editions change. The LimeSurvey GitHub repository and the Formbricks GitHub repository are the natural starting points for technical reading, but they do not replace a written statement from the vendor about what your edition includes.
The right choice depends on the use case. A research team, a public consultation, an employee pulse survey and a SaaS onboarding flow each put different weight on hosting, identity, retention and export. Weight the criteria before you send the RFP, so that a feature that matters only to one group does not decide the outcome for everyone. Use the scores as a conversation tool: a bidder with a lower total may still be the better fit if the gap sits in a criterion your use case does not need, and a high total means little if the evidence behind it is thin.
Questions to ask by area, with what a good answer contains
Which LimeSurvey or Formbricks edition fits our requirements, and why?
Start by naming the edition and the feature set you need, then ask the vendor to show which features sit in which edition. LimeSurvey Community Edition is licensed under GPL v2.0 with the option to use any later GPL version, and it is free to download and self-host. Formbricks Community Edition is licensed under AGPLv3, but OIDC and SAML SSO, teams and access roles, audit logs, and removal of the Powered by Formbricks badge sit in the Enterprise license. A complete answer lists the edition, the version (for example LimeSurvey Community Edition 7.6.0 or Formbricks 6.0.2, the versions current when this was written), each feature you require, and the edition that includes it. Ask the vendor to confirm the version is still supported on the date of signing.
What licence obligations apply if we modify or host the survey tool ourselves?
Obligations depend on the licence and on whether you distribute modified code. Under AGPLv3, Formbricks forks kept private must be released under AGPLv3 unless covered by an Enterprise license, so ask counsel to review any custom code before it goes live. Under GPL v2.0 or later, LimeSurvey modifications carry copyleft duties when distributed. A written answer names each licence, identifies which code falls under the Enterprise terms, states whether any paid licence key is needed for your feature set, and lists who holds the licence obligations after handover. Confirm that the Enterprise license key requirement is understood before the first production deployment.
How will existing survey data and responses be migrated, and what is verified?
Migration covers questionnaires, response data, question IDs, multilingual text, file uploads and user accounts, and each needs its own mapping. A good answer names the source platform and export format, the target version, the database engine, and a row-count and checksum reconciliation method. For LimeSurvey, ask the vendor to state the supported database versions (MySQL 8.0, PostgreSQL 14, MariaDB 10.3.38 or MSSQL 2019 or later) and the PHP requirement (PHP 8.1.29 or later with mbstring and PDO drivers). Cost depends mainly on the number of surveys, the data volume and how many response-level mappings must be rebuilt. Verify the migration in a test environment with a copy of production data before cutover, and confirm the rollback steps.
Where will the survey tool be hosted, and in which regions will respondent data sit?
A complete answer names the hosting model (your data centre, your cloud account, or a provider's dedicated environment), the operating system and container runtime, and the exact data location for database, backups and file storage. If you choose a cloud edition, ask for the hosting region. LimeSurvey Cloud lists regions including Germany, Finland, the UK, the USA, Canada and Australia, with Germany or Finland recommended for EU customers. Formbricks Cloud lists Frankfurt for its Hobby plan. For self-hosting, ask the vendor to confirm the Docker or Helm deployment path and who controls the keys and backups. Verify location in a test tenant by checking where the database and backups are written.
What security evidence will the vendor provide before go-live?
Ask for a written list of evidence rather than a general statement of security. A complete answer includes the architecture diagram, the hardening baseline for the operating system and web server, the encryption settings in transit and at rest, the backup and restore test records, the vulnerability management process, and the most recent independent security test report with its date and scope. Ask who performs and who reviews each test and whether findings are tracked to closure. DeployOpen runs security testing for applications and APIs, cloud and infrastructure, and AI systems, and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Confirm that any external attestation you need comes from an independent auditor.
How do identity and access controls work across roles, and which SSO protocols are supported?
Name the required roles, the number of administrators, and the SSO protocol you need. For Formbricks self-hosting, OIDC and SAML SSO require the Enterprise license, and teams and access roles are part of the same paid scope. For LimeSurvey, ask the vendor to document user roles, the authentication options in the installed version and any plugin required for SSO. A complete answer provides a role matrix, the approval flow for adding administrators, and how access is removed when staff leave. Verify each role in a test environment by logging in as a user with restricted rights and confirming that the restricted rights hold.
Which integrations are in scope, and what data leaves our environment through them?
List each integration with its direction, the data fields it carries and the destination. Formbricks integrates with tools such as Slack, Notion, Zapier and n8n, and it supports webhooks in the Community Edition, but each connector is a separate data flow to review. LimeSurvey exports are available through plugins such as ExportR and ExportSTATAxml. A complete answer includes the data map, the authentication method for each connection, the logging of outbound calls and the owner for each integration. Verify in a test environment by sending a test response and confirming that only the agreed fields appear at the destination.
How is the fixed scope defined, and what happens after go-live?
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A written scope names the platform and version, the environments to build, the migrations, the integrations, the test cases, the documentation and the handover items. After go-live, ask whether support, upgrades and continuous testing are covered by a separate retainer and what the response expectations are. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and it does not publish a price list, so a quote follows from the written scope. Ask for the change-request process and for the criteria used to decide whether a request is in or out of scope.
How hosting and migration questions change by option
When you run LimeSurvey or Formbricks in your own cloud account or data center, the vendor or partner never receives respondent data unless you send it there. The questions focus on where the database, file uploads and backups live, and who holds the administrative keys. Ask the bidder to state the exact location of the application server, database and object storage, including backup copies and log streams.
- Data location: Ask which regions, availability zones or data centers will hold the database, uploaded files and backups, and whether any telemetry or error reporting leaves that boundary.
- Export formats: Ask how responses, question structure and uploaded files are exported, and whether the export preserves variable codes and multilingual labels. LimeSurvey documents export plugins such as ExportR and ExportSTATAxml, so confirm which ones are in scope.
- Response history: Ask how historical responses are kept during upgrades, and how the bidder restores a single survey from backup without touching others.
- Question logic: Ask how skip logic, piping and quotas will be tested on the target version, since logic behavior can change between releases.
- Cutover plan: Ask who runs the production switch, how DNS and embedded links are redirected, and what rollback looks like if a live survey breaks.
Confirm each answer in writing against your own environment, because the bidder's standard runbook is not a substitute for your change records.
A managed cloud edition shifts operations to the vendor but keeps the hosting location a contract question. LimeSurvey Cloud lists hosting regions including Germany, Finland, the UK, the USA, Canada and Australia, and recommends Germany or Finland for EU customers. Formbricks Cloud lists Frankfurt for its Hobby plan. Treat the region as a fact to verify in writing, not a marketing label.
- Region confirmation: Ask which region holds primary data, replicas and backups, and whether any support tooling or subprocessors process responses outside that region.
- Export and deletion: Ask how you export all responses and file uploads, and how deletion propagates to backups and replicas within the contracted window.
- Plan limits: Ask how response caps and admin seat limits apply, and what happens to surveys when a plan lapses. LimeSurvey states that an expired Cloud subscription falls back to the Free package and keeps access to collected responses, so confirm that behavior in the contract.
- Question logic and features: Ask which question types, logic, multilingual options and integrations are available on the chosen tier, since higher tiers can gate features.
- Cutover plan: Ask how the vendor imports your existing surveys, which elements do not transfer automatically, and who signs off the go-live.
Check the regional commitments against your data protection documentation, and confirm the current plan terms directly with the vendor before signing.
Moving from an existing SaaS survey tool is the option where data is most likely to be lost in transit. Source exports often omit logic, branding, quota definitions or hidden variables, and response timestamps can shift in conversion. Ask the bidder to inventory the source platform before quoting, because the scope of a fixed-price migration depends on what must move.
- Export inventory: Ask which export formats the source tool provides (for example, CSV, Excel or SPSS), and whether question codes, option codes and multilingual labels survive the export.
- Response history: Ask how partial responses, timestamps, time zones, file uploads and deleted-but-retained records are handled, and whether a reconciliation report compares response counts before and after the import.
- Question logic: Ask which logic, piping, randomization and quota rules must be rebuilt by hand, and how each rebuilt survey will be tested against the source.
- Parallel running: Ask whether the old and new tools can run in parallel, how links are redirected, and how responses collected during the switch window are merged.
- Cutover plan: Ask for a written cutover sequence, a freeze date for the source tool, the rollback point, and who holds the source account credentials during the move.
Confirm that the source vendor's terms permit full export, since some SaaS contracts limit data retrieval after cancellation.
How to score vendor and partner answers
This sequence turns written RFP answers into a comparable record, so each bidder is judged on the same scope, the same sample work and the same evidence before any price is opened. The output is a scored shortlist that shows who can deliver the fixed scope you need, not just who lists the most features.
Send one written brief to every bidder
The procurement lead issues the same RFP or vendor brief, with the same questions, deadlines and attachments, to every shortlisted bidder at once. Keep a log of every clarification question and send each answer to all bidders so no one receives private information. The step is done when every bidder has confirmed receipt in writing and the clarification log is shared with the full group.
Require answers against one defined scope
Ask each bidder to answer every question against the same scope statement, including the platform edition, the hosting location, the number of forms or surveys and the user count you specify. Reject answers that rely on a different scope or on a generic product description. The step is done when every response restates the scope in its own words and flags any assumption it makes.
Run a shared sample survey in a non-production environment
Give each bidder the same sample survey, covering branching logic, multilingual text, a file upload question and an export to your analysis tool, and ask them to build it in a non-production environment you can inspect. Use an illustrative test survey that contains no real respondent data. The step is done when each bidder has delivered the build, a short log of the steps taken and any problems encountered.
Verify edition and licence obligations
Check each answer on the edition proposed, the licence terms that apply to that edition and any features the proposal depends on that sit behind a separate commercial licence. Confirm with the vendor and in writing which features are included without a key and which need one. The step is done when a licence matrix lists every required feature against the edition proposed and the bidder has signed off on it.
Weight security evidence and fixed-scope definition first
Score security evidence (hardening baseline, access model, encryption, backup and restore records, vulnerability handling, and the evidence provided for your compliance assessment) and the fixed-scope definition (deliverables, exclusions, acceptance criteria and change control) above feature lists. Feature breadth counts only after these are passing. The step is done when each bidder has a written score for both areas and any bidder without a clear scope or evidence is removed from the comparison.
Compare written answers before opening pricing
Score the written answers and sample build against the agreed criteria without seeing any price, using a fixed scoring sheet that two or more reviewers complete independently. Resolve disagreements in a recorded session. The step is done when the scoring sheet is signed by each reviewer and the shortlist is confirmed for pricing.
Open pricing against the same written scope
Only after the technical scores are fixed, request quotes that price the same scope, deliverables and support terms. Ask each bidder to separate one-time implementation fees from recurring support, hosting and licence costs, and to state what would trigger a change request. The step is done when all quotes are on the same scope basis and any gaps are resolved in writing before selection.
Scoring criteria for RFP responses
This table sets out what a strong vendor or partner answer looks like for each area of a self-hosted survey tool RFP, what a weak answer looks like, and which gaps should remove a bidder from consideration. Use it to score written responses before demonstrations, and treat any disqualifying gap as a reason to stop the evaluation rather than negotiate around it.
| Area | Full credit requires | Partial credit looks like | Disqualifying gaps |
|---|---|---|---|
| Edition fit | Named edition (LimeSurvey Community or Formbricks Community, or a stated Enterprise tier) matched to listed needs such as SSO, roles, audit logs and quotas, with each feature mapped to its edition | General claim that the tool 'supports SSO' or 'enterprise features' without naming the edition or license key | Feature needs that only exist in a paid edition are silently assumed to be included, or the bidder cannot say which edition they quoted |
| Licence obligations | Written confirmation of the license for the core and any modules, the bidder's position on AGPLv3 or GPL obligations for modifications, and any Enterprise license cost or key requirement | Core license named but no statement on how custom code, plugins or forks will be released or kept private | Refusal to state license terms, or a plan to ship modified code under terms that conflict with the core license |
| Migration of existing data | Defined export and import path for surveys, questions, responses and respondent metadata, with a test migration on a copy and a reconciliation report of record counts | Migration described as 'possible' with no test run, or responses migrated without question and option mapping | No plan for existing responses, or a plan that alters or drops records without an agreed retention decision |
| Hosting model | Named hosting location, server OS and database engine versions, backup and restore approach, and confirmation that data stays in the customer's chosen environment | Hosting described generically, with the data location left to the customer to decide later | Default configuration or a SaaS region that moves respondent data outside the agreed jurisdiction without written consent |
| Security evidence | Current hardening baseline, access control design, encryption in transit and at rest, logging, and recent security test results or a report summary the customer can review | Security statements without configuration evidence, or testing described as planned without a date or scope | No evidence offered, or refusal to let the customer's security team review configuration before signing |
| Support terms after go-live | Written support hours, severity definitions, patch and upgrade approach tied to vendor release status, and a named escalation path | Support offered 'as needed' with no defined response process or upgrade commitment | No post-go-live support, or upgrades that depend on the old release reaching end of support |
| Scope definition | Fixed scope with listed deliverables, acceptance criteria, exclusions, assumptions, change control and a payment schedule agreed in writing before work starts | Scope described in outcomes only, with no acceptance test or change process | Open-ended time-and-materials scope with no ceiling, or no written exclusions |
Answers that should worry you
Vendor answers to an RFP tell you as much through what they avoid as through what they promise. The cards below describe replies that should slow a decision down, and what to request instead. Most of them share one pattern: a claim with no document, version, or scope behind it.
Edition answers without a feature list
Vendors who say the product is "fully featured" without naming the edition, are hiding a licence boundary. With Formbricks, SSO, teams and access roles, audit logs and quota management sit behind the Enterprise license, not the Community Edition. Ask for a written table that maps each must-have requirement to a named edition and a license key requirement, and ask who pays for that license and on what recurring basis.
Refusal to name supported versions
If a vendor will not state the PHP version, database engine and minimum versions its platform requires, you cannot plan the server build or estimate patching work. LimeSurvey publishes its requirements, including PHP, mbstring, PDO drivers and supported database engines. Ask for the exact requirements for the release you will install, the end-of-support date for the release line, and the upgrade path to the next supported line.
No written exit or export plan
A vendor that cannot describe how you would leave is asking you to accept lock-in. Confirm in writing how responses, question structures, logic, translations and uploaded files are exported, in which formats, and whether the export includes the data needed to analyze results in tools such as R, SPSS or Stata. Ask for a tested export of a sample survey, and ask what happens to hosted data when a subscription ends.
Security evidence that is only a promise
Statements such as "we take security seriously" are not evidence. Ask for the hardening guide for the version you will run, the list of default settings you must change, the current vulnerability disclosure process, and the most recent independent test report with its scope and date. Where the vendor offers only a SaaS attestation, ask what it covers and whether it applies to a self-hosted deployment at all.
Support without response expectations
"24/7 support" or "dedicated team" means little without times to first response, severity definitions and named escalation steps. Ask for the response expectations by severity, the support hours in your time zone, how security patches are delivered and tested, and what is covered after go-live. Ask whether support covers your hosting environment or only the application code.
Open-ended scope
A proposal that says "configure and integrate as needed" cannot be priced or accepted. Fixed-scope work is defined by named deliverables, the number of surveys and forms in scope, the integrations to build, the environments to deliver and the acceptance tests that close each item. Ask for a written scope with out-of-scope items listed, change request rules and the milestones that trigger payment.
How to define a fixed scope and support terms
A fixed-scope statement should list exactly what the partner will deliver, in which environments, and with which boundaries. Ask the vendor to name each deliverable (for example, a LimeSurvey or Formbricks install, a config.php hardening pass, SSO wiring, a backup job and an upgrade runbook) and the environment it lands in: development, test and production, plus the cloud account, data center or air-gapped network that hosts them. List every integration by system and direction, such as an identity provider, a reporting database, a Slack or n8n webhook, or a statistical export pipeline, and state whether each one is built, configured only, or left to your team. Require the accessibility checks to be named by standard and by page or form type, and confirm whether the testing is automated, manual, or both.
The same statement should define acceptance criteria and exclusions. For each deliverable, ask how acceptance is shown: a test script, a sign-off checklist, a handover document, or a recorded demonstration. Documentation and training should be listed as separate items with their audience and format. Then write down what is out of scope, such as survey question design, content translation, ongoing monitoring, or changes to the Formbricks Enterprise license terms, so that change requests have a clear route. Confirm that the vendor will price changes outside the fixed scope through a written change process.
Support after go-live belongs in a separate written agreement, not in the implementation statement of work. Ask the vendor to state the support hours, response channels, severity definitions, patch and upgrade handling, and who holds the administrator credentials at handover. DeployOpen works on fixed-scope engagements and offers retainers for ongoing support, upgrades and continuous testing. Ask for the retainer terms in writing, including what is covered, what is billed separately, and how the agreement ends. Confirm with the vendor how each upstream release, such as LimeSurvey Community Edition updates, will be assessed and applied within your change window.
How DeployOpen scopes, delivers and supports survey platforms
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted survey and form platforms inside your own cloud accounts, data centers or air-gapped networks. For RFP work, we turn the answers to these questions into a written, fixed scope before any build begins.
How we scope
- We map your edition, licence and hosting questions to a written scope before any work starts.
- The scope names the platform version, hosting location, data migration set and integrations included.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing up front.
How we build
- We install and configure the chosen platform in your environment, with the database and PHP or container stack confirmed against the vendor's requirements.
- We set up access controls, single sign-on where the edition supports it, and the retention and export settings your policy requires.
- We test the forms, logic, exports and integrations against the acceptance criteria written into the scope.
How we hand over
- We document the architecture, configuration, backup and restore steps, and the evidence your auditors or data protection officer will ask for.
- We train your administrators on survey setup, user roles and data export so your team can run the platform after handover.
- We deliver the written record of what was built, tested and left out of scope, so the boundary is clear from day one.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after go-live.
- Retainers can cover version upgrades when the vendor ships a new release or ends support for an older one.
- Ask any partner to confirm in writing who patches the platform, who answers incidents and how changes to scope are priced.
