Building a Custom Consent Management Platform: A Privacy-Tech Case Scenario

Scenario Overview

This use case examines a scenario common in the privacy-tech space: a Danish company offering consent management services was relying on third-party tools to power the core of its business and decided to build a proprietary consent management platform (CMP) instead. The goal was to gain full control over the technology and product roadmap, enabling the company to develop the specific features its clients needed rather than working within the constraints of an off-the-shelf solution.

At the time the project began, the organization was an early-stage startup without an internal development team. Accessing full-service software development capabilities — frontend engineers, backend engineers, a dedicated project manager, and structured agile processes — was therefore a prerequisite for getting the project off the ground.

The Approach

MVP Scoping and Rapid Delivery

The first major constraint was time. The organization needed the MVP delivered before the GDPR came into effect, leaving a window of roughly five months to plan, build, and release a working product. To hit that deadline, the approach was straightforward: define only the essential features for the MVP, apply agile methodology, and move quickly.

Key activities during this phase included:

• In-person scoping workshops to align on vision and priorities
• Confirming the technology stack — programming languages, frameworks, cloud-computing services, and databases
• Creating a story map to outline the CMP's core features and functionalities
• Developing and releasing that initial feature set within the deadline

The project had a clear product vision from the outset, which made it possible to move at this pace without constant course corrections.

Post-MVP Development

Once the MVP was live, the development effort shifted to building out the platform's full feature set over time. This phase included:

• Building the self-serve dashboard
• Building the invoice module
• Setting up integrations and developing plugins
• Building a reporting module
• Integrating the CMP with the IAB's Transparency & Consent Framework (TCF)
• Ongoing platform maintenance

Key Components of the Platform

A fully realized CMP of this type includes several distinct components:

• Self-serve dashboard — allowing customers to manage their consent configurations without support involvement
• Website cookie scanner — scanning URLs to detect and categorize cookies and trackers
• Invoice module — handling billing and subscription management
• Google Tag Manager and Google Consent Mode integrations — enabling the CMP to work within standard tag management and advertising measurement workflows
• IAB TCF integration — ensuring compliance with the industry's standardized consent signalling framework
• Reporting module — providing customers with visibility into consent rates and related metrics

Implementation Challenges

Managing Technical Debt Alongside Feature Development

Rapid MVP development almost always creates technical debt, and this scenario was no exception. Once the platform was live and serving real customers, every subsequent development decision had to balance addressing that debt against the pressure to keep shipping new features. Design decisions were further constrained by the need to remain compatible with the existing solution for clients already using the platform — a common challenge when evolving a live product.

Browser Compatibility

Consent libraries have an unusual browser compatibility burden. Because a CMP's JavaScript runs on third-party websites, it must function correctly across a wide range of browsers, including older versions that would normally be deprioritized in modern web development. Supporting this breadth of environments requires careful engineering and ongoing testing effort.

Scaling to High Request Volume

As the platform grew, scaling became a significant technical challenge. The backend had initially been built with PHP, but PHP did not fit well with the planned microservice architecture. The decision was made to switch to Node.js, which aligned better with the architectural direction and the high-concurrency demands of a platform handling consent signals at scale.

At full scale, a CMP of this type can be expected to:

• Handle over 10 million consent requests daily
• Serve approximately 5,000 customers
• Scan around 2 million URLs every day

Technology Stack

The platform was built using a combination of technologies suited to a high-throughput, microservices-oriented architecture:

Backend & Runtime

• Node.js
• Express.js
• NestJS
• PHP / Symfony (initial backend, later transitioned)

Frontend

• React
• JavaScript / TypeScript

Messaging & Data

• RabbitMQ
• PostgreSQL
• Elasticsearch

Infrastructure

• Kubernetes
• Azure

Outcomes and Takeaways

Over the multi-year development lifecycle, the platform evolved from an MVP built under deadline pressure into a stable, revenue-generating product serving thousands of customers across Europe. The organization was able to attract significant outside investment — an outcome directly tied to having a proprietary, scalable platform rather than a dependency on third-party tooling.

The broader lessons from this type of engagement are consistent across CMP development projects:

1. Agile methodology and disciplined MVP scoping are the right tools for deadline-driven compliance projects. When regulation sets a hard go-live date, the ability to scope ruthlessly and iterate quickly is more valuable than a comprehensive upfront plan.

2. Technical debt from rapid delivery is manageable but must be actively governed. The cost of not addressing it compounds over time, particularly as the platform scales.

3. Technology choices must be validated against the architecture early. The PHP-to-Node.js transition illustrates what happens when a language or framework is a poor fit for the intended architecture — the switch is costly but necessary.

4. Browser compatibility is a first-class concern for consent libraries, not an afterthought. Any CMP whose JavaScript will run on third-party websites needs a robust browser testing and support strategy from the beginning.

5. Integrations with IAB TCF, Google Tag Manager, and Google Consent Mode are not optional features for a competitive CMP — they are baseline requirements for operating in the European market.