Operationalizing Privacy Compliance as a Solo AI Founder

The Problem

Duskglow can't legally operate without features no user would ever request.

California's SB 243 requires crisis protocol evidence logging, age verification, consent documentation with server-side proof of acceptance, incident response plans with specific notification timelines, and annual reporting on AI companion safety metrics by July 2027. New York's AI Companion Law requires recurring disclosure that the user is interacting with AI and reasonable protocols for data handling. Washington's HB 2225 prohibits manipulative engagement techniques, which means usage caps are legal requirements in addition to cost controls, and creates a private right of action allowing individual users to sue directly.

That last provision changes the risk calculus entirely. Most compliance failures surface through regulatory enforcement: investigations, fines, consent decrees. A private right of action means any single user who believes the product promoted compulsive usage can file suit independently. For a solo founder with no legal department and no corporate liability shield, one user and one lawsuit means personally defending a compliance claim. The stakes aren't “we might get fined.” The stakes are “I might not be able to operate this product at all.”

Duskglow's safety architecture (covered in the Safety Architecture case study) was driven by the same three laws. But those laws also contain an entirely separate set of data rights provisions. Safety provisions govern what the AI does. Data rights provisions govern what happens to user data. This case study covers the second half.

Across three laws plus CCPA, I counted seven distinct categories of data rights requirements: portable export, complete deletion, evidence logging, consent documentation, incident response planning, breach notification workflows, and cross-jurisdiction regulatory monitoring. Each category demanded a shipped feature. None of them appeared in any user research.

And the structural challenge runs deeper than volume. Every compliance framework I found (NIST, SOC 2, ISO 27001) assumes organizational roles that don't exist when one person is the PM, the engineer, the compliance officer, and the DPO simultaneously. Requirements don't scale down. A breach notification still needs to reach the California Attorney General within 15 days of notifying affected users, whether you have a legal department or a browser tab open to the AG's portal. The question wasn't whether to comply. It was how to build compliance into the architecture so that maintaining it wouldn't require a team I don't have.

Approach

Rate limiting is emotional design with compliance teeth.

Washington's HB 2225 prohibits manipulative engagement techniques designed to promote compulsive usage of AI companions. A daily message cap satisfies this requirement. But a compliance constraint that feels restrictive undermines the product's core value. Luna is supposed to be a companion, not a system that cuts you off.

One feature serving three masters simultaneously solved this. A 50-message daily cap on chat conversations (100 total across all modes) controls Gemini API spend, the primary cost driver for a bootstrapped product. The same cap satisfies WA HB 2225's anti-overreliance requirement by structurally preventing unbounded AI interaction sessions. And the UX decision that ties it together: when a user hits the limit, Luna delivers a warm “that's a wrap for tonight” closure message instead of an HTTP 429 error or a silent cutoff. The constraint feels like Luna encouraging healthy boundaries rather than a system enforcing a policy.

I designed the rate limit UX before the rate limit itself. The frontend shows a visible message counter so users are never surprised. Luna's closure message is contextual: a warm companion ending the evening, not a paywall. Rejecting both hard errors (honest but hostile) and silent cutoffs (invisible but confusing) meant the compliance mechanism became a trust-building interaction. A user who hits the rate limit and feels cared for is more likely to return tomorrow than one who hits a wall.

Triple-purpose alignment also simplified prioritization. When API costs, legal compliance, and user experience all point to the same feature, there's no prioritization conflict to resolve. That alignment is rare, and worth engineering toward when the opportunity exists.

Solo founder compliance means building systems, not doing tasks.

Compliance work that matters most is work that survives the next product change. Being compliant today is a checklist. Staying compliant as the product evolves (new features, new data categories, new jurisdictions) is an infrastructure problem. A larger team distributes this across a compliance officer, a DPO, and legal counsel. A solo founder builds systems that do the same job without the headcount.

Consider the incident response plan. A generic “respond to incidents” document is a checklist. What I built is 5 scenario-specific playbookscovering Supabase breach, Gemini API compromise, Luna crisis protocol failure, RLS bypass, and Vercel deployment compromise. Each includes step-by-step containment actions, evidence preservation procedures, severity classifications, and California's SB 446 notification timelines built in. The breach notification template is pre-formatted to California's statutory required headings. When a breach happens, the plan tells me exactly what to do in what order. Not where to start thinking.

That same principle drove the attorney review pipeline. Seven items flagged with provisional decisions and specific questions: Is the arbitration clause worth including? Does bedtime journaling trigger COPPA's “directed at children” classification? Which state governs the Terms of Service? Each item documents what I decided provisionally, why, and what specifically I need counsel to confirm or override. This pipeline is what makes the legal handoff survive product changes. When a new feature introduces a new compliance question, it slots into the same structure rather than becoming an ad hoc email to a lawyer.

Export format versioning solves the evolution problem for data portability. When crisis event logging was added, the JSON export schema changed. Rather than silently updating the format, I incremented the version from 1.0 to 1.1 and included the version in export metadata. If a regulatory inquiry asks what data was available for export at a specific date, the version number answers the question. New data categories update the shared collector function once, and both JSON and PDF formats pick up the changes automatically.

Even the legal documents themselves are designed for maintainability. I drafted the privacy policy and terms of service at approximately ninth-grade reading level, intended for actual users to understand, not just to satisfy a compliance checkbox. A user who understands what data you collect and why gives genuinely informed consent, which is harder to challenge in a regulatory proceeding than consent to a document nobody reads. Regulatory monitoring across three jurisdictions (California's SB 243 annual reporting by July 2027, Washington's HB 2225 enforcement by January 2027, New York's own timeline) is systematized with each obligation tracked to a specific date and deliverable. A solo founder can't rely on a compliance team flagging deadlines.

Data minimization as an architecture decision.

Every feature in Duskglow's compliance stack involved a specific decision about what notto store. Each decision was individually small. Together, they define the product's entire risk surface.

The age gate stores a boolean, not a date of birth. California's SB 243 requires age verification. The obvious implementation stores the user's DOB for future reference and analytics. I rejected that approach. The DOB value is collected, used to calculate age, and discarded. Only a pass/fail boolean persists in localStorage. The DOB itself is never written to any database. This eliminates an entire category of data from breach notification scope: if the system is compromised, there's no date of birth to leak because it was never stored.

Crisis event logging stores metadata, not message content. When Luna's crisis detection fires, the system needs an audit trail proving resources were surfaced. CA SB 243 requires evidence that crisis protocols functioned. The logging records a timestamp, the type of flag triggered, and the user ID. The actual message content (what the user wrote when they were in distress) is never stored in the crisis events table. The rejected alternative was full message logging for audit depth. But storing crisis-moment messages creates the highest-sensitivity data in the entire system: the exact content a user shared during their worst moment, sitting in a database that could be breached, subpoenaed, or mishandled. Metadata proves the protocol worked without creating that liability.

Crisis logging also follows a strict database operations pattern: INSERT, SELECT, and DELETE only. No UPDATE operations are permitted on crisis event records. Once a record exists, it can be read or deleted (for CCPA right-to-delete compliance), but never modified. A modified record can't prove when resources were actually surfaced. This preserves audit integrity by design.

Working memory sends compressed summaries to the AI vendor, not raw entries. Luna's contextual memory is built from the 10 most recent AI-generated summaries, not from raw journal entry text. The working memory block sent to Gemini on each request contains distilled themes and patterns, not the intimate, unstructured content the user actually wrote. If the vendor's data handling were ever compromised, the exposure window is compressed summaries rather than raw emotional disclosure. From a breach scope perspective, this is the difference between notifying users that “AI-generated theme summaries may have been exposed” versus “the full text of your private journal entries was exposed.”

Data export includes everything. Deletion cascades completely. These are two sides of the same principle. The JSON export pulls from four tables in parallel using a shared collector function (profile, journal entries with full conversation data, streak tracking, and crisis event metadata). Nothing is withheld. Account deletion cascades across six tables in a specific order: journal entries, streak tracking, crisis events, profile, beta allowlist, and finally the authentication record itself. No orphaned data remains. I rejected partial deletion because an orphaned record is both a compliance gap and a breach notification liability. Data you forgot about is data you can't account for in a regulatory inquiry.

Here's why these individual decisions compound. Each choice (boolean not DOB, metadata not content, summaries not raw text) seems minor in isolation. Together, they define a fundamentally different product. A system that made the obvious choice at every decision point would store dates of birth, full crisis-moment message text, raw journal entries in the AI's memory context, and potentially orphaned records from incomplete deletions. That system's breach notification would need to enumerate minor-identifying data, sensitive emotional content written during someone's worst moment, and the full uncompressed history of every user's private journaling. Duskglow's breach notification scope is email addresses, journal entries, and metadata timestamps. The gap between those two notifications (what you'd have to tell users was exposed) is entirely architectural. Every field you don't store is a liability you don't carry.

Architecture

Every regulatory requirement maps to a shipped product feature. The table below shows that mapping and, critically, the design decision behind each feature. The Design Decision column contains the rejected alternative or explicit tradeoff in every row, because the difference between “I built what the law required” and “I made deliberate choices about how to satisfy each requirement” is the difference between compliance execution and product judgment.

What I'd Do Differently

The boundary between PM compliance work and legal counsel was harder to draw than I expected. I started building Duskglow for personal use. Shifting to a public product changed the compliance posture entirely, not incrementally. The real gear-switch wasn't “add legal review.” It was recognizing that some decisions I'd been making confidently (data minimization architecture, export format design, cascade deletion ordering) were genuinely mine to make, while others I'd been treating as PM decisions (arbitration clause inclusion, COPPA classification, governing jurisdiction) required legal expertise I don't have. The 7 flagged items in the attorney review pipeline are the artifact of learning where that line falls. The instinct to either handle everything yourself or defer everything to a lawyer are both failure modes. The skill is recognizing which side of the line each decision falls on, and building the handoff for the ones that aren't yours.

Incident response planning feels premature at zero users, until you realize it's too late at one. Building 5 scenario playbooks, a breach notification template, and a severity classification system before a single user has signed in felt like the definition of premature optimization. The emotional resistance was real. This is the kind of work that feels like bureaucratic overhead when nobody is using the product yet. But the same personal-to-public shift that triggered the attorney review pipeline also made incident response non-optional. California's SB 446 notification timelines (30 days to affected users, 15 days to the AG after that) don't pause while you draft a plan after a breach. A solo founder who discovers a breach and then starts writing playbooks has already blown the timeline. The plan has to exist before the incident, or it doesn't exist when it matters.

Impact

Before the first beta user signs in, the compliance architecture is already operational. Where the Safety Architecture case study measured verification depth, this one measures whether a solo founder can credibly claim operational readiness across three jurisdictions.

All data rights provisions from CA SB 243, NY AI Companion Law, and WA HB 2225 have been translated into shipped product features before any enforcement deadline. CCPA compliance is fully operational: portable data export in dual format (JSON and PDF), complete account deletion cascading across 6 tables, and documented data handling practices. Five incident response playbooks cover the most likely failure scenarios, each with pre-written notification templates matching California's statutory requirements.

Seven attorney review items have been flagged with provisional decisions and specific questions, creating a structured handoff pipeline rather than a vague “needs legal review” note. Zero unnecessary data fields are stored. DOB is discarded after verification, crisis messages are excluded from logging, and working memory is built from summaries rather than raw entries. Breach notification scope is architecturally minimized.

Export format versioning (v1.0 to v1.1) creates an audit trail for regulatory inquiries about data availability over time. Vendor governance has been assessed: Gemini's paid tier confirmed (no training on API inputs), Supabase DPA evaluation initiated for data processing agreement coverage.

Principles

Compliance requirements are product specs written by legislators. Laws aren't obstacles to work around. They're requirements documents with unusually high enforcement penalties and no negotiation on scope. Treating CA SB 243's crisis evidence logging requirement as a product spec, with the same rigor applied to user stories and acceptance criteria, produced a better feature (metadata-only logging with audit integrity) than treating it as a legal checkbox would have. The reframe works in both directions: it makes compliance feel like product work, and it makes product decisions carry compliance weight.

Data minimization compounds. Each decision to not store something (DOB, crisis message content, raw journal entries in working memory) is individually small. Together, they define the product's attack surface, breach notification scope, and deletion complexity. Every field you don't store is a liability you don't carry. Compare the architecture against the alternative: a system that stored DOB, full crisis messages, and raw entries would face a fundamentally different risk profile, a more complex deletion cascade, and a broader breach notification obligation, with no corresponding benefit to the user.

A solo founder's compliance instinct is usually one of two failure modes: handle everything yourself, or defer everything to an expert. Build the system, not the checklist. Incident response playbooks, export versioning, attorney review pipeline, breach notification templates, regulatory monitoring. These are compliance infrastructure, not compliance tasks. A checklist tells you what to do today. Infrastructure tells you what to do when the product changes, when a new law passes, when a vendor updates their terms, or when a breach happens at 2 AM on a Saturday. For any operational discipline (compliance, security, quality) the real question is whether you'll still be compliant after the next deployment.

Know where your expertise ends and build the handoff. The attorney review pipeline contains 7 items, each with a provisional decision, documented reasoning, and a specific question for counsel. That structured handoff is a signal of professional maturity, not a limitation. The instinct to either handle everything yourself (overconfidence) or defer everything to an expert (abdication) are both failure modes. The skill is building a pipeline: here's what I decided, here's why, here's what I need you to confirm or override. This principle applies beyond legal. Anywhere a solo founder's judgment needs external validation, the pipeline pattern works: provisional decision, documented reasoning, specific question.