Why You Can't Vibe-Code a Consent Management System Under DPDP

A friend messages the group chat on Friday night: he's going to vibe-code a consent management system over the weekend. Done by Sunday, Monday if he sleeps. By Sunday at 11:58 PM, the scoreboard reads eight engineers requested and zero hired, one green checkbox that is legally decorative, 22 language translations with one community offended, nine consent states that disagree with each other, six downstream systems that have no idea a withdrawal happened, and one regulator he now thinks about at night.

That story went around because it's funny and because everyone in Indian tech recognises it. The joke lands on a real point. Under the DPDP Act, capturing consent is roughly two percent of the work. Proving it, across purposes, channels, languages, withdrawals, and audits, is the actual product. This is a walk through the exact things that break when you try to build a consent management system in a weekend, and why each one is a DPDP requirement rather than a nice-to-have.

A Checkbox Is Not Consent

The first prompt gets you a cookie banner with a checkbox. It looks done. It is not consent.

Consent under the DPDP Act has to be free, specific, informed, unconditional, and unambiguous, given through clear affirmative action, and as easy to withdraw as it was to give. A green checkbox satisfies none of those on its own. Making the checkbox bigger, or green, does not make the consent behind it valid, because validity lives in what the checkbox is tied to: a specific purpose, a specific notice the user actually saw, and a record that survives the moment of the click. The distinction between implicit and explicit consent under the DPDP Act is the first thing a weekend build gets wrong, because a checkbox can be styled to look like affirmative action while collecting nothing that proves it was.

The Question That Breaks the Database: True for What?

Around prompt 34, the build hits a wall that has nothing to do with UI. Someone asks the obvious question of a consent table with a boolean column: true for what? Which purpose? Which version of the notice? Given when? Withdrawn when? Provable how?

A single true or false cannot answer any of those. Real consent is not a flag; it's a record: the purpose it was given for, the exact notice version the data principal saw, the timestamp, the channel, the withdrawal state, and enough evidence to reconstruct all of it months later when a regulator asks. That record is what makes consent provable, and provability is the whole obligation. This is the difference a consent artefact captures, and a boolean column throws away. The weekend build's table grows to 31 columns and still cannot answer the question, because the problem was never schema. It was that consent is an event with a history, not a state.

22 Languages, and None of Them Through a ChatGPT Tab

The DPDP Rules require notices to be available in English and the 22 languages of the Eighth Schedule. The weekend approach is to paste the notice into a chat model and batch-translate. Then the Bodo translation of "withdraw consent" comes back reading as "abandon your family," and the problem announces itself.

Notice language is a legal instrument, not a content task. A mistranslated notice is an invalid notice, and an invalid notice means the consent collected under it is exposed. Getting this right needs native review and versioning per language, because what Rule 3 demands of a consent notice is precision in the language the data principal actually reads, not an approximation generated in one tab at 4 PM on a Saturday.

One Consent State, Nine Places It Has to Match

By Saturday night, the build has discovered the enterprise reality. Consent is not collected in one place. It arrives from the website, the mobile app, a branch, a call centre, a POS terminal, WhatsApp, an IVR, a chatbot, and a Google form from 2021 that marketing swears does not exist but still collects 400 emails a day.

Every one of those points needs the same consent state, in real time, in sync. When a data principal updates or withdraws consent through any channel, every other channel has to reflect it immediately, or the business is acting on stale permission somewhere. This is where consent stops being an app feature and becomes infrastructure, and it depends on knowing where all nine collection points even are, which is a data discovery and mapping problem before it is a consent problem. You cannot sync a state across systems you have not located.

Withdrawal Has to Reach Everywhere, Before the Next Campaign Fires

At 2 AM on Sunday, the build discovers DLT registration, template approval, and principal entities, the machinery behind sending a single SMS in India. Then the harder realisation lands: when a user withdraws consent, that withdrawal has to reach all downstream systems- the SMS platform, the email tool, the analytics stack, the ad audience- before the next campaign fires. Instantly, and provably.

A withdrawal that updates the consent table but not the six systems that read from it is not a withdrawal in any way the Act recognises. The user asked you to stop, and you kept going because the propagation never happened. Building that reliably, with proof that each downstream system honoured the change, is the part the checkbox demo never shows, and it connects directly to how data principal rights are actually serviced end to end rather than logged and ignored.

Rights, Deadlines, and the Consent Manager Nobody Mentioned

Sunday morning, the friend starts reading the actual law, and the doors keep opening. Users are data principals with enforceable rights. The rights carry deadlines. Withdrawing consent has to be as easy as giving it. There is a Data Protection Board. And there is a separate registered entity called a consent manager with its own eligibility rules, India incorporation, and a minimum net worth of ₹2 crore, that a weekend project cannot simply decide to be.

None of this is optional, and none of it is buildable by Sunday. The rights alone, access, correction, erasure, grievance redressal, nomination, each need a workflow that finds every copy of a person's data and actions the request inside the timeline the Rules set, with grievance redressal completed within 90 days. A structured view of these obligations sits in the DPDP Act FAQs on consent, revocation, and rights, and none of them fit inside a green checkbox.

Scale Is the Part That Fails Silently

The friend's load test is opening the app on two phones. The reality is a festival sale, two million users in one evening, every login firing a consent check. The free-tier database does not crash so much as quietly stop answering, and the consent layer that looked fine in the demo becomes the thing that takes the business down at its busiest hour.

Consent verification runs on the critical path of every authenticated action. It has to hold at peak, degrade safely, and never become the reason a transaction fails. That is a systems-engineering requirement, and it is the one a prototype built for a two-phone test has no way to anticipate.

The Honest Build-vs-Buy Answer

The weekend ends with the friend asking how long it took a real team. The honest answer is years, a full team, and people who read the DPDP Act closely, and the work is still ongoing, because the law and the Rules keep maturing. Capturing consent genuinely is easy. A competent developer can build the checkbox in an afternoon. Everything the checkbox implies, provable records, versioned multilingual notices, cross-channel sync, real-time withdrawal propagation, rights fulfilment, audit evidence, and scale, is the actual system, and it is a multi-quarter programme.

This is the real build versus buy question for DPDP compliance. Building the checkbox in-house is trivial and pointless. Building the provable system in-house is a genuine engineering programme most enterprises should cost honestly against a platform that already does it, which is the comparison laid out in consent tools versus full privacy platforms.

How Privy by IDfy Approaches Consent as a System

Privy by IDfy treats consent the way the Act does: as a provable, connected system rather than a captured click. The consent governance platform records what each data principal agreed to, versions every notice, serves multilingual notices, and propagates a withdrawal across every connected system in real time, with an audit trail that can reconstruct any consent event on demand. It connects to Data Compass for the discovery and mapping that tells you where all your collection points and downstream systems actually are, so the consent state syncs across the channels you know about and the ones you forgot.

That connection is the point the weekend build never reaches. Capturing consent is a checkbox. Proving it, across purposes, languages, channels, withdrawals, and audits, is the system, and building that system is not a weekend project.

Conclusion

Building a consent management system is not a front-end project; it is an enterprise governance programme. The checkbox is only the visible layer. The real work lies in maintaining provable consent records, serving accurate multilingual notices, synchronising consent across every customer touchpoint, propagating withdrawals in real time, supporting data principal rights, and retaining evidence that stands up to regulatory scrutiny. Those capabilities are built over years, not prompts.

The real build-versus-buy decision is therefore not about whether your engineering team can create a consent screen. It is about whether your organisation wants to spend multiple quarters building and maintaining a compliance system that must continuously evolve with the DPDP Act and its Rules, or deploy a platform that already provides those capabilities with audit-ready evidence from day one.

To see how Privy by IDfy helps enterprises operationalise consent governance across channels, systems, and business units, write to shivani@idfy.com.

FAQ's

Can you build a consent management system in a weekend? 

You can build a consent checkbox in a weekend. A DPDP-compliant consent management system, one that stores provable consent records, serves versioned multilingual notices, syncs state across every channel, propagates withdrawals to all downstream systems in real time, and holds at scale, is a multi-quarter engineering programme, not a weekend build.

What makes consent valid under the DPDP Act?

 Consent has to be free, specific, informed, unconditional, and unambiguous, given through clear affirmative action, tied to a specific purpose, and as easy to withdraw as it was to give. A styled checkbox does not meet this unless it is backed by a provable record of what was agreed, when, and under which notice.

What is a consent record and why does a boolean column fail?

 A consent record captures the purpose, the notice version the user saw, the timestamp, the channel, and the withdrawal state, so the consent is provable later. A single true or false column cannot answer which purpose, which notice, given when, or withdrawn when, which is exactly what a regulator or audit asks.

Why does consent need to sync across channels? 

Consent is collected across websites, apps, branches, call centres, POS, WhatsApp, IVR, and chatbots. When a data principal withdraws or updates consent through one channel, every channel has to reflect it in real time, or the business acts on stale permission somewhere in the estate.

Should we build or buy a consent management system for DPDP? 

Building the checkbox is trivial. Building the provable, connected system, records, multilingual notices, cross-channel sync, real-time withdrawal, rights fulfilment, audit evidence, and scale is a genuine multi-quarter programme. Most enterprises should cost that honestly against a platform that already does it.