Local AI as the Default: Build Apps That Don't Need a Privacy Policy by Moving Inference Onto the Device

A post on Hacker News climbed to the top of the charts this weekend.

The headline: "Local AI needs to be the norm."

It landed because it named something a lot of developers already feel but haven't said out loud.

Cloud AI is not free. It is fragile. And it introduces a trust problem that no privacy policy can actually solve.

What the article argues

The author's case is straightforward.

Modern devices — phones, laptops, tablets — already contain neural processors that sit idle most of the time. Apple's chips, Qualcomm's NPUs, Intel's AI accelerators. These are not future hardware. They are already in the hands of your users right now.

When you build a feature that streams user content to a third-party AI API instead of running inference locally, you are making a series of choices your users did not ask for:

• You are creating a dependency on a server that can go down, rate-limit you, or change its pricing
• You are introducing a data retention risk that exists whether or not your vendor promises to delete logs
• You are converting a simple software feature into a distributed system that needs backend management, billing, and vendor account maintenance
• You are asking your users to trust a privacy policy instead of trusting the architecture

The article's example is the Brutalist Report iOS app. It generates article summaries using Apple's local model APIs. No server transmission. No data logging. No vendor infrastructure. The summary runs on the user's device, with the user's compute, on data that never leaves.

As the author puts it: "You don't build trust with your users by writing a 2,000 word privacy policy. You build trust by not needing one to begin with."

Where the service opportunity is

The gap between "what the hardware can do" and "what most apps actually do" is enormous right now.

Most apps that added an AI feature in 2023 or 2024 did the same thing: grabbed an API key, pointed at OpenAI or Anthropic, and shipped. That was the fastest path. It still is, for many use cases.

But a growing set of tasks don't need the broad knowledge of a frontier cloud model. They need inference over data the user already owns:

• Summarize this email thread
• Classify this document
• Extract key dates from this contract
• Rewrite this paragraph
• Suggest a reply to this message

These are not hard problems for a capable on-device model. They are exactly the tasks local inference is built for.

The author makes the distinction clearly: local AI is not trying to replace cloud models that require world knowledge. It is trying to own the class of tasks where the input is user data and the output is a transformation of that data.

That class is large. And most apps handling it today are still routing it through the cloud.

The playbook

The service model here is a Local AI Conversion.

You come in as the person who audits a codebase and maps every cloud AI call the app is making. You categorize them: which ones need a frontier model, which ones can run locally, which ones are borderline.

Then you execute the migration on the local-eligible tasks using the on-device APIs available for the target platform. Apple's Foundation Models framework, Core ML for custom models, the Windows AI APIs for PC-first apps.

The deliverable is not just a technical migration. It is a positioning upgrade.

An app that runs AI locally can say something its competitors cannot: your data never leaves your device. No vendor. No logs. No privacy policy section explaining what happens when there's a breach.

That is a real differentiator in 2026. Users are paying attention. Regulators are paying attention. The teams building the products are paying attention too — they just don't always know what the migration would actually take.

That is the gap you fill.

Who to sell to

The best initial customers are indie developers and small product teams who added an AI feature in the last two years and are now quietly unhappy about the API cost, the vendor dependency, or the compliance questions.

They are not hard to find. They have apps in the App Store or on Product Hunt. They have public repos. They talk about their products on X and Hacker News. Many of them have already read this article.

You reach them by being the person who can point to Brutalist Report and say: that is what the migration looks like on the other side.

The broader pattern

The author ends with a framing worth keeping.

The goal is not ubiquitous AI. It is useful, trustworthy software.

Local AI wins where it wins because it is more trustworthy, not just because it is cheaper or faster. The privacy and the resilience and the reduced complexity are all expressions of the same underlying choice: trust the device, not the server.

That is a product philosophy as much as it is an architecture decision.

And it is one that more teams are going to be making over the next few years as the on-device models get better, the OS-level APIs get more complete, and the cost of cloud inference becomes a harder line item to justify.

Get in front of that shift now. The teams doing the migrations in the next twelve months will be the ones who can point to a track record when the rest of the market catches up.

Sources:

https://unix.foo/posts/local-ai-needs-to-be-norm/

https://news.ycombinator.com/item?id=48085821