ReConsent

1. One-liner

Watches each release for the change that legally voids parental consent, and proves you re-asked.

2. Trend signal — why now?

Texas SB 2420 — the App Store Accountability Act — is in effect right now. Not proposed, not pending. The Western District of Texas enjoined it in December 2025; on 28 May 2026 the Fifth Circuit stayed that injunction, and the law is enforceable by the Texas Attorney General while the merits appeal continues. Utah’s equivalent was pushed to 6 May 2027. Louisiana’s was pushed to 1 July 2027. Texas is the live one, and it is live today.

Here is the part that makes this a product rather than a legal alert. The statute puts a duty on developers, not just on Apple and Google. Developers must receive age-category signals from the app store, gate minor access on them, and — the load-bearing clause — obtain fresh parental consent after a “significant change” to the app.

Nobody will tell you what a significant change is.

Apple’s own age-assurance developer Q&A, when asked directly whether a given update requires re-consent, answers:

“It depends. You determine what constitutes a significant app update based on applicable laws. To determine which changes to your app are considered significant app updates, consult your legal counsel.”

Apple ships the plumbing — the Declared Age Range API and PermissionKit, added in iOS 26.2 (November 2025) — and explicitly hands the judgment back. Apple’s role stops at confirming age and passing a category. Apple states developers must independently “determine what qualifies as a significant update in their jurisdiction,” implement the gating, and handle the consent response. And Apple is unambiguous about the consequence of getting the timing wrong: “Until the parent provides consent, the child must be prevented from accessing the significant update, which may include all app and account data or specific features.”

So the platform defines the API and refuses to define the trigger. That is the whole opening.

The developers are visibly lost. On Apple’s own developer forum, in the Declared Age Range API thread, developers are asking:

“where to deal with change in user’s age or repudiation (as required by law if I read properly)”

“it remains unclear whether this solution is actually legally compliant”

“We may be forced to publish an app without thoroughly testing it works OK for so in Texas”

“AgeRangeService.shared.isEligibleForAgeFeatures is currently broken”

Bloomberg Law framed the same thing from the outside: a wave of state laws is “pushing small and medium-sized software developers into the middle of a battle between app stores and social media giants over who is responsible for verifying user ages.”

And the penalty structure is what turns confusion into spend. Texas routes ASAA violations through the Deceptive Trade Practices Act. The AG’s Consumer Protection Division can seek up to $10,000 per violation plus injunctive relief. Separately, the DTPA lets individuals bring actions for economic damages, injunctive relief, and attorney fees. That last clause is the one that matters commercially: attorney-fee shifting is what makes small-dollar claims worth a plaintiff lawyer’s time. Commentators have also noted the Act holds developers liable for knowingly misrepresenting an age rating while “fail[ing] to provide meaningful guidance to developers and stores about what metrics should be used.”

Undefined standard. Per-violation penalty. Fee-shifting private right of action. Enforceable today. That combination is the reason a two-person app studio will pay this month.

Provenance:

• Signal 1 (demand): Apple’s own age-assurance Q&A refuses to define the re-consent trigger — “You determine what constitutes a significant app update based on applicable laws… consult your legal counsel” — while making developers responsible for blocking access until consent returns; developers on Apple’s forum report the API is “broken,” “difficult to test,” and that “it remains unclear whether this solution is actually legally compliant” — https://developer.apple.com/support/age-assurance and https://developer.apple.com/forums/thread/810754 — observed 2026-09-03
• Signal 2 (feasibility): Apple shipped Declared Age Range API and PermissionKit in iOS 26.2 (November 2025) with sandbox testing, returning age bands (under 13, 13–15, 16–17, over 18) rather than exact ages — the signal a developer must react to now exists as a documented API surface — https://www.macrumors.com/2025/11/04/ios-26-2-texas-age-verification-law/ — observed 2026-09-03
• Signal 3 (economic): Texas ASAA enforceable since the Fifth Circuit’s 28 May 2026 stay; violations run through the DTPA at up to $10,000 per violation for the AG, plus a private right of action carrying attorney fees; a funded age-assurance category already exists (k-ID, $51M raised, 52 employees) but aims at platforms with 100M+ users — https://www.wiley.law/alert-Key-Developments-With-State-App-Store-Accountability-Acts-as-Texas-Act-Takes-Effect and https://www.pillsburylaw.com/en/news-and-insights/app-store-accountability-act-texas.html — observed 2026-09-03 Category: Regulatory arbitrage

3. The opportunity

The age-assurance market sells the check. k-ID, Yoti, Didit, Persona — every one of them answers “how old is this user?” at $0.10 to $3.00 a verification. That question is solved, commoditised, and in Texas’s case largely answered by Apple and Google for free through the platform age signal.

The question nobody sells an answer to is: “does this release void the consent I already have?”

That’s a different shape of problem. It isn’t identity verification, it’s release-diffing plus a legal judgment plus an evidence trail. It happens on the developer’s CI cadence, not on user signup. And it produces an artefact — a dated record showing what changed, why you did or didn’t classify it as significant, and who you re-asked — that only matters when someone comes after you eighteen months later.

k-ID is the credible incumbent and it structurally cannot serve this band. Its site has no published pricing, routes everything through “Book Demo” and “Talk to Sales,” and positions on “100M+ Users Across gaming, social, and AI platforms” and “200+ Jurisdictions” with “Enterprise SLA and 24/7 monitoring.” A company with 52 employees selling multi-jurisdiction enterprise compliance infrastructure to Discord and Bandai Namco is not going to build a $79/month release-diff tool for a solo iOS developer. It has a free tier (AgeKit) as a funnel, but the free tier does classification — not release monitoring, not the re-consent judgment, not the evidence file.

The legal floor is now far below the vendor floor. Every developer shipping an app available to Texas residents owes this duty, “even if those apps are not directed to teens or kids.” The vendor floor starts at nine-figure user counts. Everything between is unserved.

4. Target market

• Primary customer: Founder-engineer or head of mobile at a US small/mid app studio — 1 to 25 people, one to six shipped iOS/Android apps, revenue roughly $150K–$5M, no in-house counsel, no dedicated compliance hire. Consumer apps with any user-generated content, chat, social feature, purchase flow, or ad SDK. The buyer is the person who signs the App Store release, because that’s who the duty attaches to.
• Why they buy: Because they cannot answer the question Apple told them to ask their lawyer, they ship every two weeks, and the wrong answer is a fee-shifting lawsuit. In their own words from Apple’s forum: “it remains unclear whether this solution is actually legally compliant.” They are not buying age verification — the platform gives them the age band. They are buying a defensible answer to “was this release significant?” and a record that they acted on it.
• Rough TAM reasoning: The App Store carries roughly 2.0–2.2 million available apps as of early 2026, and one survey puts solo indie developers at 42% of the iOS developer community. I’m not claiming all of them. The realistic serviceable slice is US-based studios with a revenue-generating consumer app that has a minor-accessible surface and enough revenue to fear a DTPA claim — call it the low tens of thousands of studios. At $79–$299/month, a few thousand of them is a $5M business. This does not need to be a big market.
• Why now for them: Texas went enforceable on 28 May 2026. Utah lands 6 May 2027 and Louisiana 1 July 2027, so the same buyer faces a widening multi-state matrix over the next ten months — which is exactly when a per-jurisdiction rules engine stops being a nice-to-have. The customer who buys for Texas today renews for Utah next spring.

5. Product sketch (MVP)

• Release diff, classified. Connect the App Store Connect / Play Console account and the repo. On each build, produce a plain-English diff of what changed in user-facing terms — new permission, new data category, new social surface, new purchase path, changed age rating — not a code diff.
• Significance verdict with reasoning. For each release, a call: significant / not significant / borderline — re-consent recommended, with the specific statutory and platform language the call rests on, and the option to override with a reason.
• The override is the point. Every verdict, every override, every reason, timestamped and immutable. This is the artefact that exists to be handed to a lawyer.
• Age-rating change tripwire. Apple’s guidance names a changed age rating as a significant change requiring re-consent. Catch it before submission, not after.
• Jurisdiction matrix. Texas live now; Utah 6 May 2027; Louisiana 1 July 2027. Show which of your shipping states each release triggers, with dates.
• Consent-refresh checklist per release. What you must gate, for which age bands, until consent returns — mapped to the Declared Age Range categories (under 13, 13–15, 16–17, over 18).
• Counsel handoff pack. One PDF per release: what changed, the verdict, the reasoning, the action taken. The thing you forward when the demand letter arrives.

6. AI angle — what’s load-bearing

Remove the AI and this is a checklist nobody fills in.

The load-bearing work is turning a release into a user-facing change description and then classifying it against an undefined legal standard. A commit log, an Info.plist delta, a changed permission string, a new SDK in the dependency manifest, and the release notes are five different representations of “we added chat.” Reducing those into “this release introduces a new user-to-user communication surface, which is the kind of change that alters the risk profile a parent consented to” is exactly what a language model is good at and what a rules engine is bad at, because the input is unstructured and the categories are fuzzy.

The second AI job is the reasoning trail. The product’s value is not the verdict — it’s the defensible verdict. Generating a paragraph that cites the statutory language and the platform guidance, tied to the specific change, is the artefact being sold. A human lawyer produces that for $400/hour and won’t do it every fortnight for a studio with $600K of revenue.

The model is doing the paralegal’s work, on the release cadence, at a price a two-person studio pays without a meeting.

7. Localization angle (if any)

N/A — this is a US-first play by construction. The duty is created by three US state statutes with distinct commencement dates, and the enforcement teeth (DTPA fee-shifting) are Texas-specific. The natural expansion isn’t geographic localisation, it’s jurisdiction accumulation: Utah in May 2027, Louisiana in July 2027, and whichever states copy the template in the 2027 sessions. The EU and UK have their own age-assurance regimes, but those are a separate rules engine and a separate sale — not a translation.

8. Business model — path to $1M–$5M ARR

• Pricing: $79/month solo (1 app, Texas only). $199/month studio (up to 5 apps, all enacted states, counsel handoff pack). $499/month portfolio (unlimited apps, multi-jurisdiction matrix, priority verdict review).
• ACV: ~$2,400 blended, assuming the mix skews to the $199 studio tier.
• Rough math to $1M ARR: 420 studios at $199/mo × 12 = $1.0M. That’s roughly 400 US app studios out of a base in the tens of thousands.
• Rough math to $5M ARR: ~1,700 customers at a $2,900 blended ACV, which requires the tier mix to shift up as the jurisdiction count grows from one state to four or five. Utah and Louisiana landing in 2027 is the mechanical driver — the same customer’s matrix gets more complex without any new sales effort. A meaningful chunk should also come from a per-release verdict-review upsell where a human reviews borderline calls.
• Expansion path: apps → jurisdictions → seats. A studio starts with one app in Texas, adds apps, then adds states on the 2027 dates. That’s expansion revenue that arrives on a published calendar, which is unusually predictable.

9. Go-to-market wedge — first 100 customers

• The Apple forum thread is a lead list. The Declared Age Range API threads on Apple’s developer forums contain developers stating, by name and in public, that they don’t know if their implementation is compliant and that the API is broken. Reply with a genuinely useful technical answer to their actual question, then link a free “is my next release significant?” checker. This is a few dozen highly-qualified people, not a scrape.
• Free single-release checker as the front door. Paste your release notes and permission diff, get a verdict and a one-page reasoning memo, free, no account. This is the lead magnet and the demo. Gate the second release. My memory of this pattern is that free diagnostics kill paid diagnostics — which is why the free tier gives the verdict and the paid product gives the trail. One-off answers don’t defend you; eighteen months of dated records do.
• r/iOSProgramming, r/androiddev, and Indie Hackers, with the legal explainer nobody has written. Every existing write-up on Texas SB 2420 is by a law firm and aimed at general counsel. Nothing exists that says “here’s what you, shipping a SwiftUI app next Tuesday, actually have to do.” Write that, honestly, with the citations. It ranks and it circulates because it’s the missing document.
• App-development agencies as a channel. Agencies ship releases on behalf of 10–40 clients each and are now carrying an undefined liability on every one. Sell the portfolio tier to the agency, not the app. Twenty agencies is 400 apps.
• Ambulance-chase the enforcement news, ethically. The first Texas AG action or DTPA private suit against a developer will be covered widely. Have the explainer and the checker already live, and be the resource the coverage links to.

10. Build complexity — justification

Low. No custom models, no proprietary data, no infrastructure. The inputs are App Store Connect / Play Console APIs, a git provider, and a dependency manifest — all standard OAuth integrations. The classification is prompt-and-retrieval work over a rules corpus the founder curates by reading three statutes and Apple’s and Google’s published guidance. The evidence trail is an append-only table.

The genuinely hard part is not engineering, it’s the rules corpus and being right about it — which is content work, not build work. A technical founder who is willing to read the statutes ships v1 in six to eight weeks. The moat, such as it is, accrues in that corpus and in the accumulated per-customer trail.

11. Gating checklist

Gate	Pass?	Note
Legal in target market	✅	Compliance tooling; helps developers meet an enacted statute. Ships guidance, not legal advice — needs a clear disclaimer and a real one, not boilerplate.
Ethical — no harm / dark patterns	✅	The effect is more children’s consent obtained correctly, not less. No incentive to under-classify — and the product should not be tuned to tell customers what they want to hear.
Market exists (evidence above)	✅	Enacted and enforceable law, funded incumbent category, developers publicly asking the question on Apple’s own forum.
1–5 person team can build this	✅	Solo technical founder plus part-time legal review.
Launchable with <$50K / ₹40L	✅	Standard SaaS costs plus a few thousand dollars of counsel time to review the rules corpus.

12. Feasibility score

Axis	Weight	Score	Notes
Problem intensity	20	16/20	Enforceable now, $10K/violation, fee-shifting private right of action, and the platform explicitly refuses to answer the question. Not 18+ because most developers haven’t been sued yet — the pain is anticipatory, and anticipatory pain converts worse than a live invoice.
Demand evidence	15	13/15	Verbatim public confusion on Apple’s own forum, Bloomberg Law reporting the burden lands on small/mid developers, a $51M-funded incumbent proving budget exists. Short of 15 because none of that is evidence of this specific product being bought.
Build feasibility	15	13/15	Off-the-shelf APIs, no custom models, 6–8 weeks solo. The rules corpus is the work, not the code.
Distribution clarity	15	12/15	The Apple forum thread and the missing explainer are concrete and cheap. Agencies are a real channel. Not higher because there’s no clean list of “US studios shipping to Texas” to scrape — it has to be earned through content.
Revenue mechanics	15	11/15	$199/mo is defensible against a $10K-per-violation exposure and 400 customers to $1M is achievable. Docked because small studios are notoriously price-sensitive about compliance they haven’t been punished for yet, and churn after the initial scare is a genuine risk.
Time to first revenue	10	8/10	The free checker converts inside a release cycle — two to four weeks. Fast, but there’s no pre-sold pipeline on day one.
Defensibility	10	4/10	Honestly weak. The rules corpus is copyable and the accumulated trail only locks in customers who’ve been using it a year. A 6-month head start plus the explainer ranking is the whole moat.
Total	100	77/100

13. Qualitative modifiers

Founder-fit tags

technical-heavy · content-heavy

The build is straightforward; the differentiator is a founder who will actually read Texas SB 2420, Utah’s and Louisiana’s equivalents, and Apple’s and Google’s guidance, and then write the explainer that doesn’t exist. Content is distribution here, not decoration.

Key assumptions to validate (3–5)

1. Assumption: Small studios perceive re-consent timing — not age verification — as their unsolved problem. How to test: 25 conversations with US studios shipping consumer apps; ask what they did about Texas without naming the product. If they say “we use the platform age signal and we’re fine,” the thesis is wrong.
2. Assumption: They’ll pay $199/mo before any enforcement action lands against a developer their size. How to test: put the free checker live, then gate the second release behind payment. Measure paid conversion, not signups.
3. Assumption: An AI verdict on “significant change” is accurate enough to be trusted. How to test: assemble 40 real releases, have a privacy attorney classify them, compare. Below ~85% agreement the product is a liability generator rather than a liability reducer.
4. Assumption: The law survives the Fifth Circuit merits appeal. How to test: unhedgeable — track the docket. See kill criteria.

Risk flags

1. Litigation risk — the law may be struck down. This is the big one. Texas SB 2420 is under active First Amendment challenge from CCIA and from SEAT; a district court already found it “more likely than not an unconstitutional content-based regulation” before the Fifth Circuit stayed that ruling. If the merits appeal goes against Texas, the Texas-only wedge evaporates. Mitigated but not removed by Utah (May 2027) and Louisiana (July 2027) being separately enacted with different enforcement mechanisms — but those face similar challenges.
2. Platform dependency, and a platform that may absorb the feature. Apple and Google define the API surface. If Apple decides to publish a definitive “these changes are significant” list, the core judgment disappears overnight. Apple’s current posture — punt to your lawyer — is what creates the gap, and Apple can reverse it in a release note. The evidence trail survives that; the verdict doesn’t.
3. Liability exposure on the product itself. Selling a verdict on an undefined legal standard means being wrong sometimes. This needs real disclaimers, E&O insurance, and a product that presents borderline calls as borderline rather than manufacturing false confidence.
4. Anticipatory pain converts badly. My repeated experience with deferred-liability products is that they only sell when paired with something already costing money weekly. Here the weekly wedge is the release cadence itself — every two weeks the question recurs — but that’s a weaker hook than an invoice.

14. Structured verdict

Score:                  77/100
Verdict:                GO
Confidence:             Medium
Best-fit builder:       Technical founder who ships mobile apps and will read the
                        statutes themselves; part-time privacy counsel on retainer
Time to revenue:        4–8 weeks from launch
Capital to launch:      $8–15K (mostly counsel time for the rules corpus + E&O)
Top 3 assumptions to validate first:
  1. Studios name re-consent timing (not age checks) as the open problem —
     25 unprompted interviews
  2. Paid conversion off the free single-release checker exceeds 4%
  3. AI significance verdicts agree with an attorney on ≥85% of 40 real releases
Kill criteria:
  - Abandon if the Fifth Circuit strikes down SB 2420 on the merits AND Utah's
    or Louisiana's commencement dates slip again past mid-2027
  - Abandon if Apple or Google publishes a definitive list defining "significant
    change" — the judgment layer is then worthless
  - Abandon if attorney agreement on the 40-release benchmark comes in below 85%
  - Abandon if fewer than 15 paying customers after 90 days of the free checker
    being live

15. Next step — 1-week validation sprint

• Day 1–2: Read Texas SB 2420, Utah’s and Louisiana’s Acts, and Apple’s and Google’s published age-assurance guidance end to end. Build the 40-release benchmark set from real public App Store release histories of small studios. Draft the significance rubric.
• Day 3–4: Ship the free single-release checker — paste release notes plus permission diff, get a verdict and a reasoning memo. No auth, no billing. Simultaneously run the checker across the 40-release benchmark and get a privacy attorney to classify the same 40 independently.
• Day 5: Post the missing explainer to r/iOSProgramming and answer three live questions in the Apple Declared Age Range forum threads with real technical help plus a link.
• Decide go / no-go on: attorney agreement ≥85% on the 40-release benchmark, and ≥30 checker runs from distinct studios in the first week, and ≥5 of those studios replying yes to “would you pay $199/mo to have this run on every release and keep the record?”

Agreement below 85% kills it regardless of demand — a compliance product that’s wrong 1 time in 5 on an undefined standard makes its customers worse off, and I won’t ship that.