Thinking about
privacy, on-device
software and craft

The cloud AI bargain

Every time you type a message into a cloud AI app, that text travels to a server somewhere. It gets processed, stored, potentially reviewed, and used to improve the model. You get a useful answer. The company gets your data. That's the implicit bargain — and most people don't realize they've made it.

We thought about this a lot when we started building AIJJ. The apps we wanted to make — tools for writing, thinking, working — would handle sensitive content. Business emails. Lesson plans. Drafts you haven't published yet. The kind of content people wouldn't want floating around in a data center.

"The best feature we could ship was never sending your writing to our servers in the first place."

Local processing is no longer a compromise

For years, doing everything on the device meant accepting worse tools. That has changed. Modern phones are more than powerful enough to handle focused productivity tasks — drafting a business email, planning a lesson, outlining a blog post — entirely locally, with no server in the loop.

For focused, single-purpose tools like ours, local processing is more than good enough. A lesson planner doesn't need a data center. It needs well-designed software that applies clear structures to what you enter and produces clean output. That's fully achievable on-device.

What this means for you

When you use an AIJJ app, the text you type is processed and stored on your device. Our apps don't send it to our servers or to any third-party service. The work happens in the same place your data lives — your phone. We have no way to see it, and no interest in collecting it. Two things are worth knowing: if iCloud Backup is turned on, iOS may include app data in your device backup, which you control; and purchase and subscription status is handled through Apple and RevenueCat, as described in our Privacy Policy.

That's not a limitation of our business model. It is our business model. Privacy by architecture, not by policy.

↑ Close article

The platform trap

There's a common pattern in productivity software: a tool starts focused, gains users, then adds features until it becomes a platform. Notion, Slack, Microsoft Teams — all began with a clear purpose and grew into ecosystems. That growth often comes at a cost to the original experience.

Features compete for attention. The interface grows cluttered. The tool that once helped you focus now demands configuration, maintenance, and onboarding. The thing that saved you time now costs it.

The focused tool advantage

A tool that does one thing can optimize for that one thing completely. The interface can be stripped to essentials. The engine can be tuned for one type of task. The onboarding can be instant. You open it, you use it, you close it.

"We don't build platforms. We build precise instruments."

This is the philosophy behind AIJJ. Each app we build covers one job and the writing around it. Tactworks handles business emails. Slateroom handles lesson planning. Draftmill handles content drafts, from blog outlines to video hooks. They don't try to do each other's job. They don't come with dashboards, integrations, or notification systems. They open fast, do the work, and get out of your way.

Better for the App Store ecosystem too

There's a practical benefit as well. A focused app can rank for a specific search query in the App Store far more effectively than a Swiss Army knife app. "Lesson plan maker" is a search term with clear intent. An all-in-one productivity suite ranks for nothing in particular.

Our matrix approach — building a suite of focused tools under one developer identity — lets each app compete on its own terms, while the AIJJ brand creates trust across the portfolio. It's a different way of thinking about product strategy, and so far, it's the one we believe in.

↑ Close article

Privacy as marketing vs. privacy as architecture

Almost every app claims to take privacy seriously. Privacy policies run to thousands of words. Cookie consent banners appear on every website. And yet the data collection continues — it's just disclosed now, in documents no one reads.

Real privacy doesn't come from policies. It comes from architecture. The only way to truly protect user data is to never collect it in the first place. You can't leak what you don't have. You can't be compelled to hand over what doesn't exist on your servers.

What "on-device" really means

When we say our apps run on-device, we mean exactly that. When you use the app, your input is processed by software running on your device. The result is computed locally and displayed to you. Your content is not sent to our servers or to any third-party service. Purchases are verified through Apple and RevenueCat, and if iCloud Backup is turned on, iOS may include app data in your device backup, as our Privacy Policy explains.

"We have no servers that receive your content. Not because we deleted it — because it was never sent."

This is architecturally different from a privacy policy that says "we don't sell your data." A company can commit to not selling data and still collect it, store it, analyze it internally, and expose it in a breach. We eliminate that entire risk surface by design.

The trade-offs we accept

This approach requires trade-offs. On-device tools can't draw on the scale of cloud infrastructure. They don't improve from harvesting user interactions the way cloud services do. We can't offer cross-device sync without building our own sync infrastructure (which we've chosen not to do).

We think these are the right trade-offs. The apps we build are tools, not platforms. They produce output you use elsewhere — an email you send, a lesson you teach, a post you publish. The quality of that output needs to be good, not perfect. And for the tasks our apps handle, on-device software today is genuinely good.

Why this matters more in 2026

AI has made the data collection problem significantly worse. Every interaction with a cloud AI is a detailed behavioral record. Your questions reveal your anxieties, your work, your relationships, your plans. That's a rich dataset for advertisers, insurers, employers, and governments — whether or not anyone intends it to be used that way.

Building tools that run locally is one of the few ways to offer useful writing and planning tools without participating in mass behavioral surveillance. You can see what that looks like in Tactworks, Slateroom and Draftmill. We think it's worth the engineering complexity. And we think users increasingly agree.

↑ Close article