The Case for On-Device Apps

Most software today assumes your data belongs in the cloud. You upload a file, a server processes it, and you trust that the company on the other end handles it well and deletes it when it should. For a lot of everyday tasks, that trade is not necessary, and at CarbonApps it is the one we try hardest to avoid.

We build small, fast tools that run on your device. The file never leaves your Mac or your browser tab. That single constraint shapes almost everything about how the apps feel to use.

What "on-device" actually means

On-device means the work happens locally, using your own machine's processor, with no round trip to a server. A transcription app transcribes on your Mac. A file tool converts the file in the browser. Nothing is uploaded, nothing is queued on someone else's hardware, and there is no account required to do the work.

That is different from most web tools, which send your input to a backend, process it there, and send the result back. Convenient, but it means your data has been on a stranger's server, however briefly.

Why we prefer it

Three reasons, in order of how much they matter to us.

• Privacy by default. If the data never leaves your device, there is no server log to leak, no breach to worry about, and no policy to read carefully. The most private way to handle a file is to never send it anywhere.
• Speed. Local work has no upload time and no queue. For anything larger than a few megabytes, skipping the round trip is often faster than the cloud version, not slower.
• It keeps working. No subscription server to go down, no API to deprecate, no rate limit. An app that does its work locally will still do it years from now.

Cloud vs. on-device, honestly

On-device is not always the right answer. Some work genuinely needs a large model or shared data that only a server can provide. But a surprising amount of everyday software, converting a file, transcribing a recording, cleaning up a spreadsheet, does not. When it does not, we think local is simply the better default.

How this shows up in the apps

The pattern repeats across what we build. A transcription tool that runs the model on your Mac instead of uploading your audio. File converters that do the work in the browser so the document never touches a server. Utilities that ask for no login because there is nothing to log in to.

The point is not to be purist about it. It is that when we can keep your data on your device without making the app worse, we do, and most of the time the app is actually better for it.

The tradeoff we accept

Building this way is harder for us. Running work locally means dealing with different machines, different browsers, and the limits of a laptop instead of a fleet of servers. It also means we cannot see how people use the apps, which removes an easy source of feedback. We think that is a fair price. The apps are yours, they run on your hardware, and your files stay with you.

If that is the kind of software you want more of, take a look at what we have built.

Common questions

Does on-device mean the app is slower? Usually the opposite for larger files, because there is no upload step or server queue. Very heavy tasks that need a big model are the exception.

Do these apps work offline? Most of the core work does, because it runs locally. Anything that genuinely needs the internet is the exception, not the rule.

Why does this matter for privacy? Data that never leaves your device cannot be logged, leaked, or retained by anyone else. It is the simplest privacy guarantee there is.