US state privacy laws: A state-by-state guide for app builders

A healthcare SaaS company based in Texas launched their patient engagement app in 2024. They'd built HIPAA compliance into every layer. What they hadn't considered was that their app also collected email addresses, device IDs, and browsing behavior from non-patient visitors in 19 states. Six months after launch, they received a letter from the Colorado Attorney General's office asking about their data processing practices and opt-out mechanisms.

They had none. The app had no consent management, no opt-out flow, and no data subject access request system for non-patient users. Retrofitting those features across their existing architecture took 14 weeks and cost $180,000 - three times what it would have cost to build it right from the start.

This is the reality of US privacy law in 2026. There's no single federal standard. Instead, there are 20+ state laws, each with different rules about who's covered, what data counts, and how users can opt out. If your app has users in more than one state - and most apps do - you're dealing with a patchwork.

Who does this apply to?

The short answer: almost every business with an app or website that collects user data.

Each state defines its own thresholds for which businesses are covered. Some are based on revenue. Others are based on how many consumers' data you process. A few have no revenue threshold at all.

Here's the general pattern. Your business is covered if it meets any one of these criteria in a given state:

• Annual revenue above a certain threshold (typically $25 million)
• Processes personal data of a certain number of consumers (typically 100,000+)
• Derives a significant percentage of revenue from selling personal data (typically 50%+)

The catch: these thresholds vary by state. A small SaaS company with 50,000 users and $5 million in revenue might be exempt in California but fully regulated in Colorado (which has a lower processing threshold). Texas has no revenue requirement at all - if you sell personal data, you're covered regardless of company size.

The practical rule: If your app collects personal data from US users and your business has any meaningful scale, assume at least one state law applies to you.

The IAPP's US State Privacy Legislation Tracker monitors active and pending state privacy bills in real time. As of 2026, over 20 states have enacted comprehensive consumer privacy laws, with new bills advancing in multiple states each legislative session. This patchwork isn't stabilizing - it's growing.

What the laws require: State-by-state comparison

Every US state privacy law shares a common DNA. They all give consumers some version of the same rights and impose similar obligations on businesses. But the details - thresholds, consent models, enforcement mechanisms - differ enough to matter.

The big six: Laws every builder should know

The next wave: States enacted 2023-2026

Beyond the big six, these states have enacted privacy laws with effective dates between 2024 and 2026:

Universal consumer rights

Despite the differences, every state grants some version of these five rights:

1. Right to know - consumers can ask what personal data you've collected about them
2. Right to delete - consumers can request deletion of their personal data
3. Right to opt out - consumers can opt out of the sale of personal data (and in most states, targeted advertising)
4. Right to correct - consumers can request corrections to inaccurate data
5. Right to portability - consumers can get a copy of their data in a portable format

The differences are in the details. California lets consumers opt out of "sharing" data (not just selling), which covers cross-site tracking for advertising. Some states require opt-in consent for processing sensitive data like biometrics, health information, or precise geolocation. Minnesota includes a right to question automated decision-making.

How it affects your app architecture

Privacy law compliance isn't a policy document you stick on your website. It's a set of architecture decisions that affect how your app collects, stores, processes, and deletes data. Here's where the rubber meets the road.

Consent management layer

Every state requires some form of consent mechanism. At minimum, you need:

• A cookie/tracking consent banner that lets users opt out of non-essential data collection
• A "Do Not Sell or Share My Personal Information" link visible on every page (California requires this exact language)
• Global Privacy Control (GPC) signal detection - California, Colorado, Connecticut, Montana, and Texas require your app to honor the GPC browser signal as a valid opt-out request
• Sensitive data opt-in flows - if you collect biometrics, health data, precise geolocation, or data about minors, most states require affirmative opt-in consent before processing

Architecture decision: Build consent as a middleware layer, not a page-level feature. Every data collection point in your app should check the user's consent state before processing. If consent is revoked, data collection stops immediately - not on the next page load.

Data subject request (DSR) system

Every state gives consumers the right to access, delete, and correct their data. Your app needs a system to handle these requests within the legally required timeframe (typically 45 days, with a possible 45-day extension).

This means your architecture needs:

• A DSR intake form or email process that logs requests with timestamps
• Identity verification before fulfilling any request (you can't send someone else's data to a random requester)
• A data inventory - you need to know every place a user's data lives (your database, analytics tools, email marketing platforms, third-party integrations)
• Automated or semi-automated deletion workflows that purge data across all systems, not just your primary database

Architecture decision: If your user data lives in 5+ systems (database, CRM, analytics, email platform, payment processor), manual DSR fulfillment won't scale. Build an automated data map and deletion pipeline from the start. The alternative is hiring someone to manually track down data across every system for every request.

Data minimization

Maryland's MODPA and several newer state laws include data minimization requirements. You can only collect data that's "reasonably necessary" for the purpose you've disclosed to the user. This affects your data schema directly.

What this means in practice:

• Don't collect data "just in case" - every field in your registration form needs a documented business purpose
• Analytics tracking should be scoped to what you actually use for product decisions
• Third-party SDKs that collect device fingerprints, advertising IDs, or browsing history may violate minimization requirements unless you've disclosed them

Children's data

If your app is likely to be used by minors (under 13 in most states, under 16 in California for targeted advertising), additional restrictions kick in. California requires opt-in consent for users under 16. Several states require parental consent for users under 13, aligning with federal COPPA requirements.

Architecture decision: If there's any chance minors will use your app, build an age-gating mechanism. This doesn't have to be a hard wall - a simple date-of-birth check during registration that routes minors through a restricted data collection path.

The California strategy: Build once, comply everywhere

Here's the practical reality. You have two options:

Option A: Build separate compliance logic for each state, checking user location and applying different rules. This is technically correct and practically insane. The maintenance burden alone will eat your engineering team alive.

Option B: Build to the California CPRA standard and apply it to all US users. California is the strictest. If your app satisfies CPRA, it satisfies Virginia, Colorado, Texas, and every other state law currently on the books.

Option B is what every compliance-aware engineering team we've worked with chooses. Here's what that looks like:

1. Treat all personal data as sensitive by default. Require opt-in consent for sensitive categories. Provide opt-out for everything else.
2. Honor GPC signals globally. Don't check whether the user is in a state that requires GPC recognition. Just honor it for everyone.
3. Respond to DSRs within 45 days. California's timeline. Most other states give 45 days too.
4. Include the California-specific disclosures. "Do Not Sell or Share My Personal Information" link, categories of data collected, purposes of processing, and retention periods.
5. Apply data minimization. Collect only what you need. Document why you need it.

The cost difference between Option A and Option B is negligible at build time. But Option A creates ongoing engineering overhead every time a new state passes a law. Option B is a one-time architecture investment.

"We've built apps where the business insisted on California-only compliance because 'those are our main users.' Two years later, they had 50,000 users in Texas and had to retrofit opt-out flows and DSR handling across an architecture that wasn't designed for it. The retrofitting cost more than building it universally from the start, and their legal team was nervous for six months. The math on Option B is clear."

• Ashit Vora, Captain at 1Raft

What compliance costs vs. what non-compliance costs

Building it right: $30,000-$80,000

This is the incremental cost of building privacy compliance into your app's architecture from the start:

• Consent management platform integration - $5,000-$15,000 (OneTrust, Osano, or custom build)
• DSR handling system - $10,000-$25,000 (intake form, identity verification, automated deletion workflows)
• Privacy policy and disclosures - $5,000-$10,000 (legal review for multi-state compliance)
• GPC signal handling - $2,000-$5,000
• Data inventory and mapping - $5,000-$15,000
• Testing and QA - $3,000-$10,000

Retrofitting after launch: $90,000-$250,000+

When privacy compliance is an afterthought, the costs multiply:

• Architecture changes - $30,000-$80,000 (adding consent checks throughout existing data flows)
• Data migration - $15,000-$40,000 (restructuring databases to support deletion and portability)
• Re-engineering third-party integrations - $10,000-$30,000
• Legal review and remediation - $15,000-$40,000
• Lost development time - 8-16 weeks of your team diverted from product roadmap

Non-compliance penalties

• CPRA - up to $7,500 per intentional violation. With 10,000 affected users, that's $75 million in theoretical exposure.
• Most other states - $2,500-$7,500 per violation, enforced by the state attorney general.
• Colorado - up to $20,000 per violation, the highest state-level fine.
• Data breach costs - average $4.88 million per incident according to the IBM 2024 Cost of a Data Breach Report, plus mandatory notification costs in every state.

The math is clear. A $50,000 upfront investment in compliance architecture saves you from six- or seven-figure exposure later.

Questions to ask your development partner

Before you sign a contract with any development team, ask these questions. Their answers will tell you whether they've built privacy-compliant apps before or are figuring it out on your dime.

1. How do you handle multi-state consent management? Look for: a middleware or service-layer approach, not page-by-page logic. They should mention GPC signal handling without you bringing it up.

2. Walk me through your DSR fulfillment architecture. Look for: awareness that user data lives across multiple systems, automated deletion workflows, identity verification before fulfilling requests. Red flag: "We just delete the database record."

3. How do you approach data minimization in the schema design? Look for: documented data collection purposes, audit of third-party SDKs and their data collection, distinction between required and optional data fields.

4. What's your testing process for privacy compliance? Look for: specific test cases for opt-out flows, DSR processing, consent state persistence, and GPC signal handling. Red flag: "Our QA team tests it manually."

5. Have you built an app that needed to comply with CCPA/CPRA specifically? Look for: specific examples, not generic claims about "understanding privacy." Ask for the architecture approach they used.

6. How do you handle privacy law changes after launch? Look for: awareness that new states pass laws every year, architecture designed for extensibility (new consent categories, new rights), ongoing monitoring. Red flag: "We'll cross that bridge when we come to it."

Your compliance checklist

Use this checklist to verify your app meets the requirements of major US state privacy laws. If you build to this standard, you'll satisfy California's CPRA and, by extension, every other state law on the books.

If you're building an app that serves US users and you're not sure which state laws apply, the safest approach is to build to the California standard and apply it universally. The engineering cost is nearly identical, and you'll be protected as new states pass their own laws.

For teams that want privacy compliance built into the architecture from sprint one - not bolted on before launch - that's exactly how we build at 1Raft. We've shipped compliant apps across healthcare, fintech, and SaaS, and the compliance work starts in the first architecture sprint, not the last.