How to Build Market Research Software: The Seven Decisions That Are Expensive to Reverse

Building market research software involves seven important decisions: the tenancy model, response schema, what to reuse, quota management, respondent status, compliance requirements, and the order in which the platform is built.

The first six are architecture decisions. The last one is about development sequence.

All of them are easier and cheaper to decide early. Once clients are using the platform and real projects are running, changing these foundations becomes much more difficult.

This guide focuses on the technical side of the build. Questions around business model, MVP scope, and budget are covered separately in OnGraph’s guide to building a self-service research platform.

Decision 1: The Tenancy Model, Before Any Schema

A market research platform usually serves multiple clients. How you separate their data should be decided before designing the rest of the database.

Microsoft’s Azure Architecture Center describes tenant isolation as a range of options rather than a simple shared-versus-dedicated choice. A platform may use fully isolated infrastructure, fully shared infrastructure, or something in between.

That decision affects security, cost, performance, reliability, and how easily individual client requirements can be handled.

Many platforms begin with a pooled model: one database with rows separated by tenant.

AWS Prescriptive Guidance documents this approach using PostgreSQL row-level security. In this setup, the application sets a tenant value for the session, and PostgreSQL policies use that value to filter queries.

There are two implementation details that matter here.

First, PostgreSQL row-level security policies do not apply to the table owner unless FORCE ROW LEVEL SECURITY is enabled. If the application connects as the table owner without this setting, the policy may not provide the isolation you expect.

Second, connection pools reuse database sessions. The tenant context should therefore be set with SET LOCAL inside the transaction. Otherwise, one request may inherit the tenant setting from a previous request.

AWS also points out the limitations of pooled tenancy. It states that “the noisy neighbor phenomenon cannot be completely eliminated in a pool model” and that some SaaS customers may require stronger isolation than RLS provides.

Research agencies can face this requirement from pharmaceutical, financial services, or other enterprise clients.

For that reason, it is useful to create a tenant-to-deployment mapping layer from the beginning. This makes it easier to move a particular client to dedicated infrastructure later without rewriting the application.

Market research platforms have another requirement that standard SaaS guidance does not always cover: the respondent may be shared across clients.

If the same panel serves several clients, the platform cannot simply separate respondent identity by tenant. Participation history, exclusion periods, and reward balances may need to remain tied to the same person across projects.

A practical model is to keep project and response data tenant-specific while maintaining a controlled cross-tenant respondent registry.

Decision 2: A Response Schema Built for Analysis

Survey data creates a database challenge because each questionnaire can introduce a different set of fields.

This often pushes teams toward entity-attribute-value storage, where every answer is stored as a separate row.

That approach can become difficult to manage.

Reconstructing one respondent may require joins or pivots. Values are often stored in generic string fields, which moves validation into the application. Large volumes can also create extra indexing and write overhead.

A common alternative is JSONB combined with typed columns for the fields that need frequent analysis.

There is also a separate decision between wide and long data formats.

Stef van Buuren’s Flexible Imputation of Missing Data notes that wide format makes calculations such as means, change scores, and correlations between time periods easier. Long format is more flexible for irregular or missing waves.

A research platform therefore does not have to choose one format for every use case.

One approach is to keep a canonical system-of-record format, such as long-form data or JSONB, and generate wide datasets as versioned analysis outputs when needed.

Pivoting everything at query time does not scale well for large research programs.

For example, a tracker with 200 variables, 50,000 respondents, and 12 waves produces more than 100 million answer rows. Rebuilding a wide structure every time someone runs a banner or significance test can become expensive.

Two other areas should also be designed early.

Weighting Data

Weights should be part of the data model, but they should not simply be added as permanent columns to the respondent table.

A study may have several weight sets at the same time, such as:

• national weights
• wave weights
• subgroup weights
• post-stratification weights

These can also change as fieldwork progresses.

A better structure is a separate table keyed by respondent, weighting scheme, and version.

Raking, which is commonly used by public polling organizations such as Pew Research Center, works from marginal population proportions, so the storage requirement itself is manageable.

Open-Ended Responses

Open-ended responses should also be treated as more than a single text field.

Verbatim coding assigns responses to a codeframe. In tracking studies, that codeframe may change over time.

If codeframe versions are not stored, comparisons across waves can become unreliable.

For platforms that exchange research data with other systems, Triple-S remains an established open interchange standard using separate metadata and data files.

Decision 3: What to Reuse — and What the License Permits

Survey engines can take much more work to build than they initially appear to.

SurveyJS estimates that a basic form builder could require around 12 months of work from five developers, or roughly 60 person-months. That estimate excludes conditional logic, and features such as responsive design and theming can increase the effort further.

The estimate comes from a vendor that sells survey components, so it should be viewed in that context. Even so, it shows why many teams reuse an existing survey engine instead of building everything from scratch.

The licensing model then becomes important.

SurveyJS Form Library

SurveyJS Form Library uses the MIT license.

It can be used inside closed-source software as long as the required copyright and permission notice is included.

Survey Creator, Dashboard, and PDF Generator use commercial licensing and are priced per developer.

LimeSurvey

LimeSurvey uses GPL v2.0 or later.

Running a modified version on your own servers does not automatically require you to publish those modifications.

However, code delivered to the user’s browser can be treated differently. GPL JavaScript sent to respondents is distributed code, so the corresponding source obligations need to be considered.

LimeSurvey’s survey runner contains substantial JavaScript.

Because of this, assuming that a hosted product can always remain completely closed-source is risky.

Its logo and visual assets are also registered trademarks, so a white-label implementation needs proper rebranding regardless of the software license.

Formbricks

Formbricks uses several licensing models.

Its client SDKs are MIT licensed. The server core uses AGPLv3, while the enterprise directory is proprietary and requires a commercial license.

AGPL section 13 applies when users interact remotely with modified software over a network. Respondents completing surveys can fall into that category.

There is another important consideration.

The difference between hosted and distributed software only applies while the software remains hosted by you.

If you deploy a white-label system inside a client’s infrastructure, provide a container image, or offer on-premise installation, the licensing implications can change significantly.

In that case, GPL or AGPL obligations may affect the commercial model, not just the technical implementation.

This licensing discussion is useful for initial planning, but it is not legal advice. License obligations depend on the exact code used, modifications made, deployment model, and current license terms. Legal review is recommended before finalizing the architecture.

Reuse also has limits.

SurveyJS supports features such as conditional visibility, branching, piping, carry-forward logic, and more than 50 community-supported locales.

Quota management, however, is not part of the same feature set.

That leads to one of the more difficult parts of a research platform.

Decision 4: The Quota Engine Is a Concurrency Problem

At first glance, quotas look like simple counters.

The problem appears when many respondents qualify or complete at nearly the same time.

Qualtrics explains this directly in its documentation:

“Quota information is not saved until the respondent submits their survey… Because more than 1 person can enter the survey at a time, there is a chance that multiple people submit answers at the same time, possibly resulting in going over quota.”

If several respondents submit during the same period, the final quota count can exceed the intended limit.

Those extra completes may still cost the agency money even if the client does not accept them.

A better design is to reserve quota capacity when the respondent qualifies for a particular cell.

This should happen after screener answers determine eligibility.

It is too early to reserve at survey entry because the system does not yet know which quota applies. Waiting until final submission can be too late.

The reservation should work like a temporary lease rather than a permanent lock.

Some respondents abandon surveys without triggering a clean exit event. Reservations therefore need an expiry time and a process that regularly releases expired reservations.

This introduces another trade-off.

Too many active reservations can make a quota appear full even when some respondents will never complete. The reservation period should therefore be based on realistic completion times rather than an arbitrary value.

Research quota logic also goes beyond a simple maximum number.

Forsta Decipher documents:

• non-interlocking quotas
• interlocking quotas
• randomly assigned quotas
• priority quotas
• least-filled handling when respondents match several cells

Qualtrics supports simple and cross logic along with multiple actions when a quota is reached.

A research platform built for agencies generally needs comparable flexibility.

Another interaction also needs to be tested carefully.

Qualtrics documents that question randomization can override page breaks, questions-per-page settings, and skip logic.

These conflicts should be handled during development rather than discovered during live fieldwork.

Decision 5: How Respondent Status Is Modeled

A respondent may enter from a sample supplier with an identifier, pass through screening, and leave the survey with an outcome that affects supplier and client billing.

That makes respondent status more than a front-end label. It becomes part of the commercial record.

Sample providers often use strict outcome codes.

Cint, for example, allows specific redirect codes from client survey systems, including complete, terminate, overquota, and quality or security termination.

It also recommends server-to-server status reporting because S2S can reduce problems such as ghost completes and data loss.

There are two important design implications.

Redirect Status and Commercial Disposition Are Different

The redirect status is sent when the respondent exits.

That event should remain recorded as it happened.

However, the commercial outcome may change later.

A complete can be reversed after:

• quality review
• later fraud detection
• supplier reconciliation
• invoice adjustments

If the platform stores only one final immutable respondent status, there is nowhere to record these later changes properly.

A better model keeps the original emitted status and a separate commercial disposition with its own history.

Status Processing Must Be Idempotent

Webhook events may be delivered more than once and may arrive out of order.

Handlers should therefore deduplicate using the provider’s event identifier.

Using only the respondent session as the deduplication key can create another problem. A single respondent may legitimately generate multiple events, such as qualification followed by completion.

Those events should not be treated as duplicates.

Ordering also needs separate handling.

If the provider sends timestamps or sequence numbers, the platform can use them to prevent an older event from overwriting a newer state.

A reconciliation process is still useful for finding events that never arrived.

Redirect security also matters.

If a respondent outcome is passed as an editable URL parameter without signing or encryption, the respondent could potentially change it.

This is why suppliers often require hashed or encrypted return parameters and define separate failure codes for invalid returns.

The wider integration architecture is covered in OnGraph’s guide to key integrations required in a market research platform.

Decision 6: Compliance Encoded in the Schema

Market research platforms may need to support GDPR in Europe, US privacy laws such as CCPA/CPRA, industry codes, and research certification requirements.

These requirements should affect the software design rather than being handled only through policy documents.

GDPR Article 4(5) defines pseudonymisation as processing data so it cannot be attributed to a person without additional information that is stored separately and protected.

From a software-design perspective, that supports separating identity data from research response data and joining them only through controlled identifiers.

Article 7 requires organizations to be able to demonstrate that consent was given and makes consent withdrawal an important part of the process.

The platform therefore needs a reliable consent record that can store:

• timestamp
• consent status
• notice version
• withdrawal history

Article 30 requires records of processing activities.

For software used by research agencies, some of this record-keeping may need to become part of the product itself.

There are also practical conflicts to resolve.

For example, an audit or consent log may need to remain unchanged while a participant has the right to request deletion of personal information.

One technical approach is to encrypt personal data using a subject-specific key. When an erasure request is processed, destroying that key makes the personal information unreadable while leaving the audit record in place.

Deletion can also become more complicated when datasets have already been delivered to clients.

The system therefore needs a process for propagating erasure requests rather than deleting information only from the main application.

The 2025 ICC/ESOMAR International Code adds another consideration.

Article 6(c) requires researchers to take steps to prevent individuals from being identified through deductive disclosure, including when advanced analytics or AI are used.

In software, this can translate into controls such as:

• minimum cell-size suppression in outputs
• field-level restrictions on data sent to subcontractors

For agencies pursuing ISO certification, ISO 20252:2019 Clause 4 provides part of the operational framework.

A revision reached the FDIS stage in 2026, so current clause numbering should be checked against the latest edition before implementation.

Decision 7: The Order the Build Follows

Martin Fowler’s well-known monolith-first argument says that many successful microservice systems began as monoliths and were separated later.

The reason is practical.

It is difficult to define good service boundaries before the team fully understands the product domain.

For an initial market research platform, a single deployable application with well-defined internal modules can therefore be more practical than starting with many independent services.

The more important question is what should be built first.

It does not necessarily need to be the survey engine because that component can be licensed.

The respondent session and outcome layer deserves early attention because real fieldwork depends on it.

It controls:

• respondent identity
• qualification
• outcome handling
• supplier status
• payment-related events

It is also difficult to replace after the platform is already processing live respondents.

Most other modules either read from this layer or write to it.

Two non-functional requirements should also be addressed early.

Traffic Peaks

Fieldwork traffic is rarely uniform.

Most survey invitations are opened shortly after a send, and reminders create additional spikes.

Capacity planning should therefore focus on peak traffic rather than only average daily volume.

Data Residency

Some enterprise clients require data to remain in particular regions.

Qualtrics, for example, allows customers to choose between several regional data centers and supports contractual arrangements for data transfers.

If your platform may need similar flexibility, regional hosting should be included in the architecture early.

It is much harder to add after all data has been designed around one global deployment.

The Bottom Line

The basic feature list for market research software is already well understood.

The more difficult decisions are behind those features.

A useful question for every major architecture choice is:

How difficult would this be to change after the first enterprise client is already using the platform?

Tenancy, response schema, quota handling, and respondent status are particularly difficult to change later.

That is why these decisions should be made early in the build rather than left for future development.

Where OnGraph Fits

OnGraph builds research platforms through custom market research software development and white-label deployment.

These projects can include tenant architecture, versioned response structures, supplier-integrated fieldwork, quota management, respondent workflows, and reporting.

Related capabilities include market research project management software for workflows from bidding through invoicing and a survey creation tool for self-service research.