The DPDP Act applies to your app if you build in India or serve people in India. The GDPR applies as well once you offer the app to people in the EU. Both laws want the same things from your software: a stated reason for each piece of personal data you collect, deletion when a user asks, reasonable security, and fast breach reporting. Building the app with an AI tool changes none of that. What follows translates both laws into features and checks. I am an engineer, so treat this as the technical half of the job and take the legal half to a lawyer.

Which law applies to your app, and when both do

Both laws put the duties on whoever decides why and how personal data is used. India calls that business a data fiduciary and the GDPR calls it a controller. For an early-stage app, it is the founder.

The DPDP Act covers digital personal data processed in India, and it follows the data abroad when the processing is linked to offering goods or services to people in India. A Noida founder with Noida users is covered. So is a founder in Singapore selling to customers in Pune.

The GDPR covers businesses established in the EU, plus those outside it that offer goods or services to people in the EU or monitor their behaviour there (Article 3(2), if you want the text). "Offering" is the word carrying the weight. A few Europeans who find your English-language, rupee-priced app on their own do not usually bring you under the GDPR. Euro pricing, EU-targeted marketing or a German translation start to. The European Data Protection Board sets out the signals in its Guidelines 3/2018 on territorial scope.

An Indian startup selling into Europe answers to both laws at once, and most of the engineering work serves both.

What both laws ask your app to do

Translated out of legal drafting, the shared duties come down to six things your software has to do.

First, it tells people what it collects and why, before collecting anything. Lawyers call this a notice. The DPDP Rules want it standalone, itemised and readable, which rules out a policy three clicks deep in the footer.

Each use of data also needs a lawful reason, and for most startups that reason is consent. Consent must cover a specific purpose, come from a clear action, and be as easy to withdraw as to give. In practice you store a record of which user agreed to which version of the notice, for what, and when. Without that record, you have no way to show the consent happened.

People can ask to see, correct or delete their data, and the request has to work through the app and through every system behind it. The users table is the easy part.

Security has to be reasonable. Neither law names tools, but both expect encryption, access control and some way of noticing trouble.

Breaches get reported fast: to the regulator within 72 hours of finding out, and to affected people on terms that differ between the two laws.

Finally, data goes once its purpose is over. Storing everything in case it proves useful is the habit both laws were drafted against.

As a fintech tech lead I sat through enough audits to see the pattern. The smooth ones belonged to teams that could trace a single customer's data through every system from a document they already kept. The painful ones began with someone promising to check with whoever built a service.

Where the DPDP Act and the GDPR differ

The differences are fewer than the overlaps, but each one reaches into your code.

For an early app, three of these rows cause most of the trouble when they are missed.

Analytics comes first. Under the GDPR, some product analytics can rest on legitimate interests. India's Act offers no general basis like that, so for Indian users, plan on consent for anything beyond delivering the service they signed up for.

Age is next. India treats everyone under 18 as a child and requires verifiable consent from a parent before you process a minor's data, a far higher bar than Europe's. If teenagers could plausibly sign up, work out how you will handle them before you build onboarding.

Then breaches. The DPDP Rules set no risk threshold: every personal data breach goes to the Data Protection Board and to the people affected, with a detailed report to the Board within 72 hours. That only works if you detect breaches in the first place, and detection is the piece I most often find missing when I review AI-built apps.

Hosting in India with European users adds a further wrinkle. The EU has not granted India an adequacy decision, so moving EU users' data to Indian servers needs a safeguard such as standard contractual clauses (EU-approved contract terms signed by sender and receiver).

Why AI-built apps lose track of personal data

Both laws assume you know where your users' data lives. Apps built from prompts make that hard, because every prompt adds code that works, and working code often sends data somewhere new without saying so.

In the generated apps I have reviewed, logs are usually the first culprit. Request logging that captures whole request bodies quietly copies every email address and phone number a user types into files nobody treats as a database. Analytics and error-tracking scripts come next, added to answer a question about drop-off and picking up form fields on their way to a third-party dashboard. AI features are the newest leak, such as a summary that sends a user's entire record to a model provider when two fields would do.

Your notice mentions none of these places, and your delete button reaches none of them. Erase a user and the database row goes while the copies stay.

My kitchen works the same way on a long Sunday cook. If I cannot say which shelf holds the spices, I cannot find the one that has gone off. A data map is that shelf list for your app.

Owning your code is what lets you draw the map. I reviewed Mayson's architecture out of professional curiosity, and the relevant part here is that you own the generated code, so you can read where user data goes and change it when a law asks you to account for it. No builder, Mayson included, makes an app compliant for you. Compliance depends on what you collect, what you tell people and how you respond when they ask, and those choices stay with you.

What to build before your first user signs up

You do not need a compliance platform for any of this, and every item costs less now than after launch.

A data map. A single table with a row for each piece of personal data, covering what it is, why you collect it, where it is stored, which outside services receive it and how long you keep it. Fill it in by reading your code, since memory leaves gaps.

A versioned notice with consent records. For each user, store the notice version they saw, the purposes they agreed to, the time and the method. Put withdrawal in account settings, one click deep, and make sure it switches off the processing it covers.

A delete flow that reaches every copy. Work from the data map so the request clears each location, or records why something stays, such as an invoice tax law makes you retain. I have never dropped a production table by accident, though I have watched colleagues manage it. Removing one person's data deliberately, from every system, is the harder job.

An export. When someone asks what you hold on them, they should get a readable file within days, whether from a button or an email request.

Logs you can keep for a year. The DPDP Rules expect a year of logs that help detect unauthorised access, so design them to record events without copying what users typed.

Contracts with every processor. Your hosting, email, analytics and AI providers all handle personal data on your instructions, which makes them processors. Both laws expect a contract with each. The GDPR calls it a data processing agreement, and most large providers let you accept theirs online.

Breach detection and a one-page plan. Alert on unusual access, decide who gets the 3 a.m. call, and write down whom you notify and how. Seventy-two hours goes quickly when you are still looking for the cause.

The dates that matter in 2026 and 2027

India is phasing the DPDP regime in. The primary source is the DPDP Rules, 2025 (G.S.R. 846(E)), notified by MeitY on 13 November 2025, and G.S.R. 843(E), issued the same day, sets out the Act's own phases.

People misread 13 November 2026 as a general deadline. It is the date consent managers can register, meaning intermediaries that let someone give and withdraw consent across many apps in one place. You may integrate with one later. You do not need one, and the date starts none of your duties.

May 2027 still stands. The Supreme Court has heard challenges to the Act through 2026 and issued notice on a news publishers' petition on 27 October 2026, having said earlier in the year that it would not stay the Act's operation. Build for the law as it stands.

The GDPR itself is unchanged. On 21 October 2026 the Council agreed its negotiating position on the Digital Omnibus, a package of proposed simplifications, but the European Parliament has yet to settle its own position and the two have not started negotiating. Breach reporting shows the gap between proposal and law. The Commission's proposal and the Council's position both stretch the deadline from 72 to 96 hours, while the 72-hour rule is what applies today. The Legislative Observatory tracks the file as procedure 2025/0360(COD).

When you need a lawyer, not a checklist

This article is not legal advice. It covers the part of compliance that lives in code. Contracts, notice wording and risk calls need someone qualified, and four situations justify paying for that before launch.

Children are the clearest case. If minors could use your app, India's verifiable parental consent and Europe's age thresholds both need careful handling, and the DPDP ban on tracking children changes how you build analytics and personalisation.

Health and financial data is another. The GDPR places health data in a stricter category, and in India sector regulators such as the RBI layer their own rules on top of the DPDP Act for financial products.

EU users at scale bring their own questions. Once you are plainly offering the app to Europeans, you will probably need an EU representative (a named contact inside the EU, under Article 27) and a lawful route for moving their data to wherever you host.

Watch, too, for signs you could be designated a Significant Data Fiduciary. The government can give that status based on the volume and sensitivity of the data you process, and it brings an India-based Data Protection Officer, independent audits and impact assessments. If you hold sensitive data on large numbers of people, raise it early.

Take your data map to the first meeting. A lawyer who can see where every field goes spends less of your money working it out.

Frequently asked questions

Navya is a senior backend engineer with more than 15 years in production systems. She studied computer science at IIT Kanpur, spent five years on payment infrastructure at a large product company in Bangalore, and was a tech lead at a fintech startup as it grew from thousands to millions of transactions a day. She now doe staff-level consulting and writes plain-language explainers on how software is built and how it breaks. She is not a lawyer.