Data Retention Controls
Delete data you no longer need, on a schedule, instead of keeping everything forever.
What it adds
Configurable retention windows per data type, with a scheduled job that deletes expired records and everything derived from them.
What your agent is told to do
6
What your agent is told to do
6-
1
Build a data map first: every table, file store, log stream, search index, cache, and third-party processor that holds customer data, and how old the oldest row is.
-
2
Define a retention window per data type, not one window for the whole app. Activity logs, uploaded files, and billing records have different obligations.
-
3
Run deletion as a scheduled, idempotent, batched job that can be stopped and resumed, and that records what it deleted in an audit trail.
-
4
Support legal holds: a flag that exempts a record, workspace, or user from deletion until it is cleared, and that survives the job being re-run.
-
5
Delete derived copies at the same time — search index documents, thumbnails, exports, cached aggregates, and data pushed to analytics or support tools.
-
6
Do NOT delete without a dry-run mode and a grace period. A retention job with an off-by-one window can destroy years of data in one run, and there is no undo.
Edge cases it handles
7
Edge cases it handles
7- Backups are not covered by live deletion. State the backup retention period explicitly and accept that deleted data persists there until backups roll off.
- Deleting a parent row can orphan or cascade into children — decide per relationship, and count rows in the dry run.
- Records under legal hold must be skipped without failing the batch or silently resetting their expiry.
- Retention windows differ by plan and region; a per-workspace override must not be overwritten by the global default.
- Data already sent to third parties needs a deletion call to those APIs, and some will not have one — document that gap.
- A job that times out mid-batch must not delete a record's rows in one table and leave the rest behind.
- Changing a window from 24 months to 6 months queues a very large first deletion — throttle it rather than running it in one pass.
Definition of done
9
Definition of done
9- Every store of customer data appears in the data map with a stated retention window.
- Windows are configurable per data type and overridable per workspace.
- The deletion job is idempotent, batched, resumable, and auditable.
- Legal holds prevent deletion and survive repeated runs.
- Derived data, files, search indexes, and third-party copies are removed alongside the primary record.
- A dry-run reports exactly what would be deleted before anything is.
- Backup retention is documented and distinguished from live deletion.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Age Verification Gate
Age Verification Gate
Ask visitors to confirm their age before restricted content, and remember the answer.
What it does
An interstitial on age-restricted pages that records a confirmation and does not ask again on every visit.
How it works
- 1 Apply the gate only to the pages that genuinely need it. Gating an entire site, including its help and legal pages, drives away visitors who were never going to see the restricted content.
- 2 Store the decision the same way the app already stores Consent and Cookie Preferences, and put the age confirmation in that same preference record rather than inventing a second cookie with its own expiry rules.
- 3 Give a refusal a real destination: an explanation page, or the site the visitor most likely came from. A blank screen or an infinite redirect loop reads as a broken site, not a policy.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/age-verification-gate
Data Anonymization
Data Anonymization
Strip identity out of old records without wrecking your reporting.
What it does
An irreversible scrub of identifying fields across the schema that keeps rows, relationships, and aggregate counts intact.
How it works
- 1 Classify every column as identifying, quasi-identifying, or non-identifying. Free-text notes and file names carry identity too and are the ones teams forget.
- 2 Replace identifying values in place rather than deleting rows, so foreign keys stay valid and historical counts do not change.
- 3 Make the replacement irreversible: random or tokenized values with no stored mapping back to the original. If a lookup table exists, this is pseudonymization, not anonymization — call it that.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/data-anonymization
Consent and Cookie Preferences
Consent and Cookie Preferences
Let users decide about optional tracking before the scripts load.
What it does
A consent layer that blocks non-essential scripts and storage until the user allows them, and records the choice as proof.
How it works
- 1 Inventory every script, pixel, embed, and cookie the app sets, and classify each as strictly necessary, functional, analytics, or marketing.
- 2 Block non-essential categories from loading at all until consent exists. Loading a tracker and then asking is not consent.
- 3 Store the choice with a version, timestamp, and how it was given, so a later policy change can re-prompt only the people it affects.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/consent-and-cookie-preferences
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.