When to Build Custom Panel Management Software: The Obligations That Decide It

OnGraph’s published estimate puts custom panel management software development at $30,000–$70,000+, compared with $10,000–$15,000 for white-label software and $5,000–$10,000 for a pre-built tool.

Meanwhile, Vendr’s marketplace data for Qualtrics, based on 321 purchases and last updated in February 2026, puts the median annual contract at $30,000, with prices ranging from $7,000 to $139,920.

In other words, a custom build can cost roughly the same as one year of enterprise research software.

So price alone does not decide whether a company should build or buy.

The bigger question is what happens after launch.

When you buy a panel platform, the vendor handles many of the ongoing responsibilities. When you build your own, those responsibilities move to your team.

There are five major areas to consider. They require ongoing attention and usually do not appear in the original development estimate.

The practical question is not only, “Can we afford to build it?”

It is also:

Can we manage these responsibilities over the long term, and does owning the platform create enough value to justify them?

For a detailed cost breakdown, OnGraph covers this separately in its guide to what it costs to build panel management software.

This article focuses on the costs and responsibilities that a development quote normally does not include.

Should You Build Custom Panel Management Software?

Custom panel management software makes the most sense when your panel is a core business asset, your workflows do not fit standard platforms, you need extensive integrations, or SaaS pricing no longer works at your scale.

Consider a custom build when:

• Your proprietary panel is central to your business.
• Existing platforms cannot support your workflow.
• You need deep integrations with supplier, reward, CRM, or data systems.
• Per-panelist or per-response pricing has become too expensive.
• Client contracts or data-residency requirements limit your SaaS options.

Consider SaaS or white-label instead when:

• Your panel is relatively small.
• Standard software already covers most of your needs.
• Your team does not have clear owners for compliance, deliverability, incentives, and fraud.
• Your main issue is with one vendor rather than the category itself.

This gives readers the short answer first. The sections below explain the responsibilities behind that decision.

What a Build Quote Includes, and What It Doesn’t

A development estimate usually covers the software itself.

That may include:

• registration and profiling
• admin dashboards
• segmentation and sampling
• survey assignment
• reward redemption
• reporting

These are standard panel management software features that a capable development team should be able to deliver.

Most of them are one-time development tasks.

The responsibilities discussed below are different.

They do not disappear once the software is launched.

They involve regulators, email providers, panelists, finance teams, and fraud prevention. Someone needs to manage them for as long as the panel is active.

This is also one of the main differences between panel software and survey software.

A survey tool mainly collects responses.

A panel platform maintains an ongoing relationship with identified participants.

That relationship creates responsibilities around consent, privacy requests, incentives, communication, and fraud.

This is also why comparing panel management platforms can be difficult.

Many products ranking for terms such as survey panel software and respondent management software are built for UX or product-research teams managing a few hundred participants.

Those tools may handle scheduling, screeners, and incentives well.

But managing a 200,000-member consumer panel is very different.

At that scale, the platform may need:

• a consent register
• points and incentive accounting
• email reputation management
• large-scale profiling
• long-term participant history

Both may be called panel management software, but their operating requirements are very different.

Obligation 1: Consent Is a Lifecycle, Not a Checkbox

Under GDPR Article 7(1), when processing is based on consent, the controller must be able to demonstrate that the person gave consent.

For a panel operator, that means keeping evidence for each panelist.

The system may need to show:

• what the person was told
• what they agreed to
• when they agreed
• which version of the privacy notice applied

That requires a versioned audit record, not simply a yes/no consent field.

Article 7(3) adds another important requirement:

“It shall be as easy to withdraw as to give consent.”

If someone can join the panel with one click but must email support to leave, the process may not meet that requirement.

Consent also becomes more complicated during migration.

When a panel moves to a new platform, existing consent was originally given to a particular controller for specific purposes.

Whether that consent remains valid depends on whether those conditions remain the same.

Changing the legal basis later is not always a reliable solution either. European data-protection guidance has stated that a controller cannot simply switch to legitimate interest after consent has been withdrawn.

This means re-permissioning may sometimes be necessary.

And re-permissioning can reduce panel size because some members will not respond or agree again.

That is why panel management software migration should be treated as a planned project rather than just a data export.

A commercial platform normally provides consent records, withdrawal workflows, and versioning.

With a custom platform, your organization becomes responsible for maintaining and updating those processes.

What this means if you build: Your platform needs a versioned consent record, simple withdrawal process, and a clear owner responsible for keeping both aligned with current privacy requirements. 

Obligation 2: Data-Subject Rights Run on a Statutory Clock

GDPR Article 12(3) requires organizations to respond to data-subject requests without undue delay and generally within one month.

That period may be extended by another two months when necessary because of complexity or volume.

However, the individual must be informed about the extension and the reason for it within the first month.

Article 12(5) also states that these requests are normally handled free of charge.

A fee or refusal may only apply when a request is manifestly unfounded or excessive, and the controller must be able to demonstrate that.

Three types of requests are especially relevant for panel operators.

Access

The platform may need to collect everything held about one panelist, including:

• profile information
• study participation
• incentive history
• communication records

Erasure

The system may need to delete personal information while still keeping whatever is required to prevent the person from being recruited again.

A suppression list can itself contain personal data, so this process needs careful handling.

Portability

Under Article 20, individuals may request their personal data in a structured, commonly used, machine-readable format.

Where technically feasible, the data may also need to be transferred directly to another controller.

There is a separate time limit for data breaches.

Article 33 requires certain personal-data breaches to be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of them.

If reporting happens later, the delay must be explained.

With a small participant database, some of this may be handled through a shared inbox.

At larger panel sizes, it becomes an ongoing operational process supported by software and staff.

The deadline still applies if the developer who originally wrote the export tool is no longer available.

For this reason, teams considering custom panel management software should treat data-rights handling as an ongoing operating responsibility rather than simply another feature.

What this means if you build: Someone must own access, deletion, portability, and breach-response workflows, and the software must make those requests easy to complete within the required deadlines.

Obligation 3: Deliverability Becomes an Asset the Firm Owns

A panel only has value if you can reach its members.

Sending thousands of survey invitations is no longer as simple as connecting an SMTP server.

Since February 1, 2024, Google’s requirements for bulk senders apply to senders delivering 5,000 or more messages per day to personal Gmail accounts.

Requirements include:

• SPF
• DKIM
• DMARC
• TLS
• valid forward and reverse DNS
• one-click unsubscribe for applicable messages
• spam-rate monitoring through Postmaster Tools

Google recommends keeping reported spam rates below 0.30%.

Yahoo introduced similar requirements on the same timetable.

That 0.30% limit turns email deliverability into an ongoing operational issue.

A poorly targeted survey invitation campaign can increase complaint rates quickly.

The result may include:

• throttled delivery
• messages going to spam
• rejected email
• slower fieldwork

Restoring sender reputation can take time and usually requires more careful sending practices.

When using a hosted panel platform, the vendor may manage much of the sending infrastructure and respond to changing mailbox-provider requirements.

With a custom platform, your organization is responsible for sender reputation and the domain used to communicate with panelists.

What this means if you build: Email authentication is only the starting point. Your team also needs to monitor complaints, bounces, unsubscribes, and sender reputation throughout ongoing panel recruitment and fieldwork. 

Obligation 4: Incentive Balances Are a Liability, Not a Feature

Points and unredeemed rewards are more than a dashboard setting.

They represent future value that the company may still need to provide to panelists.

That creates an accounting obligation.

Outstanding points may need to be valued using the expected value per point and adjusted for the percentage likely to be redeemed.

Under IFRS 15 and ASC 606, revenue associated with points that are expected never to be redeemed, known as breakage, is recognized based on the pattern of actual redemptions rather than being treated as income immediately.

This means the estimate needs to be reviewed over time.

Program rules can have a large impact on the result.

One public example comes from Greenfield Online’s 2008 SEC correspondence.

It reported unclaimed incentives of:

• 7.4%–12.5% of gross incentive expense in North America
• 25.2%–47.6% in Europe

for FY2005–07.

Greenfield linked much of that difference to notification rules.

In North America, panelists were notified and generally had 30 days to return to active status.

In Europe, the company stated that it was not required to notify panelists before incentives were forfeited.

The figures are old, but they show how strongly redemption rules, expiry periods, and notification policies can affect the amount.

The practical point for a custom build is simple.

A redemption threshold is not only a UX decision.

It can affect the company’s financial liability.

If a company wants full control over those rules, custom software provides that flexibility.

But finance should be involved when those rules are designed.

What this means if you build: Reward thresholds, expiry rules, and redemption policies should be agreed with finance before development because they affect both panelist experience and financial liability. 

Obligation 5: Fraud Defense Needs Continuous Attention

Fraud prevention is one area where larger commercial platforms can have an advantage.

A platform serving many customers can see attack patterns across multiple panels.

A custom platform sees only its own traffic.

That means fraud controls are only as effective as the tools and monitoring used to keep them current.

This does not mean a company has to develop fraud detection from scratch.

Services are available for:

• device fingerprinting
• IP intelligence
• proxy detection
• duplicate detection
• identity verification

A custom platform can integrate these services through APIs.

This is why survey panel integration and third-party API integrations can be more important than building an in-house fraud algorithm.

The limitation is that a single organization does not get the same cross-customer visibility that a large commercial provider may have.

So the budget should include both fraud-service subscriptions and someone responsible for reviewing and adjusting fraud rules over time.

What this means if you build: Plan for third-party fraud tools as ongoing integrations, not one-time development work, and assign someone to review thresholds as fraud patterns change. 

Custom vs White-Label vs SaaS Panel Management Software

Simple rule: choose SaaS for speed, white-label for greater ownership without taking on the full technical burden, and custom development when the software itself needs to match a business model or workflow that standard platforms cannot support.

So When Is Building Actually Right?

A custom build can make sense, but company size alone is not enough to justify it.

There are several situations where owning the platform can provide real value.

The Panel Is the Product

If the company sells access to a proprietary audience, the panel itself may be a major business asset.

Examples include:

• hard-to-reach professional communities
• longitudinal cohorts
• specialist industry panels
• category-specific audiences competitors cannot easily reproduce

In these cases, relying completely on a third-party system of record may create a strategic dependency.

The Workflow Does Not Fit Existing Platforms

Most research companies have some unique processes.

That alone is not a reason to build.

The stronger case is when the workflow has structural requirements that available platforms cannot support.

Examples include:

• different reward and tax rules across countries
• unusual recruitment models
• white-label client environments with separate data access
• CATI and CAWI workflows using the same respondent record

Integrations Are the Main Requirement

A company may already have several systems in place, such as:

• supplier APIs
• reward APIs
• CRM
• data warehouse
• client portals

If most of the project involves connecting these systems together, building a custom platform may sometimes be easier than trying to adapt a closed product.

Usage-Based Pricing Has Become Too Expensive

Per-user, per-panelist, or per-response pricing can become expensive at high volumes.

At that point, the company can compare its current annual software cost with the cost of building and maintaining its own system.

The break-even point can be calculated from real usage and invoices.

Data Residency or Contracts Require It

Some clients or jurisdictions may require data to be stored in specific infrastructure or locations.

If those requirements rule out a multi-tenant SaaS platform, the choice may already be made.

This is a requirement rather than a preference.

There are also clear reasons not to build.

A custom platform may not be the right choice when:

• the company’s main advantage is methodology or client relationships rather than technology
• nobody owns the five ongoing responsibilities described above
• the panel has only a few thousand members
• the main problem is dissatisfaction with one particular vendor rather than with SaaS panel software in general

In the last case, changing vendors may solve the problem without taking on the cost and responsibility of building software.

The Option Most Firms Actually Want

There is also a third option: white-label panel management software.

A white-label platform can give a company:

• its own branding
• its own domain
• its own panelist experience
• control over its data

while the underlying platform and infrastructure are maintained by someone else.

OnGraph explains this model in its guide to white-label panel management software.

A useful way to think about the decision is to separate ownership from construction.

If you want control over the brand, data, panelist experience, and roadmap—but do not want to maintain the full platform yourself—white-label is often the middle option worth evaluating.

Many companies asking for custom panel management software primarily want control over:

• branding
• panelist relationships
• data
• roadmap

They do not necessarily need to build every part of the technology themselves.

Where that is the case, white-label software may provide most of the benefits at a lower cost and with less ongoing technical responsibility.

Where OnGraph Fits

OnGraph develops custom and white-label research panel management platforms rather than only offering a standard off-the-shelf product.

Its published panel management software capabilities include:

• recruitment across regions and channels
• registration-based profiling
• survey-to-respondent matching
• respondent lifecycle management
• reward redemption
• custom incentive programs
• six reward API integrations
• GDPR-related controls
• fingerprint validation
• mobile verification
• panelist communication tools

Its broader market research software development offering reports more than 65 global panel integrations and 40+ API integrations, along with more than 8 million completed surveys.

Custom or white-label development does not remove the operating responsibilities discussed in this article.

Someone still needs to manage:

• consent
• privacy requests
• email deliverability
• incentive accounting
• fraud prevention

The companies that manage a custom platform successfully usually decide who owns each of these responsibilities before development begins.