On July 1, 2026, a law most founders have never heard of went into effect in Utah, and it’s worth ten minutes of your attention even if you don’t have a single user there. The Digital Choice Act, also known as HB 418, requires social media companies to let people take their data with them: posts, comments, likes, connections, and the social graph itself, in a format the bill describes as open, transparent, and third-party accessible. Utah’s Division of Consumer Protection can fine violators up to $2,500 per incident, rising to $5,000 for repeat offenses.
Nobody is going bankrupt over this fine schedule. What matters is the shift underneath it. For fifteen years, the default architecture of consumer software has been built to keep data in. This law, narrow as it is, is a state government telling companies that’s no longer entirely their call.
What the law actually requires
HB 418 doesn’t mandate a specific protocol. It requires that a user’s data, on request, come out in a form that’s actually usable somewhere else, not a format so proprietary or so stripped of structure that “portable” is technically true and practically false. Social graphs count: your connections, your content, other people’s reactions to your content, and the metadata tying it together. The law applies to social media companies specifically, so a B2B tools company or a niche vertical app isn’t in scope today. But Utah passed this with a 64-1 vote in the House, and it joins a wave of 20-plus states that now have comprehensive privacy statutes on the books. Laws like this tend to start narrow and generalize. CCPA did the same thing to the rest of the country over the following five years.
Why this is harder than it looks for most products
Here’s the part that should worry technical leaders more than the fine schedule does. Most platforms weren’t built with an exit in mind. Data models get denormalized for query speed, relationships get flattened into join tables that don’t map cleanly back to “a social graph,” and the export feature, if it exists, is a CSV dump somebody wrote in an afternoon two years ago and nobody has touched since. Complying with the letter of a law like this is an engineering sprint: build an endpoint, pick a JSON shape, ship it. Complying with the spirit, an export that’s actually usable by a competing product, means your data model has to be legible from the outside in a way most systems never planned for.
We’d bet most affected companies ship the minimum version. A button that produces a zip file nobody outside the legal team ever opens. Technically compliant, practically useless, and a missed chance to find out whether your own data architecture makes sense once you’re forced to explain it to someone else’s system.
What local-first architecture gets right by default
This is the part that connects directly to how we build. In a local-first system, the user’s data lives on their device first and syncs outward through a protocol you already had to make legible, because the client needs to read and write it independently of the server being up. Portability isn’t a compliance feature you bolt on after a regulator asks. It’s a side effect of the architecture already being honest about what the data is and who it belongs to. When we build local-first software for a client, the export problem mostly doesn’t exist as a separate problem, because the sync layer was never designed to be a one-way door.
That’s not a small distinction. It’s the difference between a company that can answer “what happens if a customer wants their data out” in one sentence, and one that needs a project plan.
What this means if you’re building now
If you’re not a social media company, Utah’s specific statute doesn’t touch you yet. But the question it’s forcing (can a user actually leave with what they came with) is going to keep showing up, state by state, and eventually in whatever federal privacy framework finally lands. If you’re scoping a new product today, decide now how data gets out, not after a user or a regulator asks. Retrofitting portability into a system that was never designed to expose its own structure is expensive and it shows: half-finished exports, missing relationships, formats nobody else’s software can actually read.
The honest tradeoff is that building this way from day one costs a little more up front. You’re choosing a data model that has to make sense to an outside reader, which is a real constraint on how fast you can move early. We think it’s worth it, and we think regulation is going to keep making that choice for people who don’t make it themselves. If you’re weighing this for a product you’re about to build, get in touch.