Why everything I build runs on your device

I run three products on my own. Sonir is a macOS app that runs your playback through DSP on its way to the DAC. Pixmend is an image restoration tool that runs in the browser. gpdf is a PDF generation library for Go. They cover unrelated ground, but they share one design decision: none of them sends your data to a server of mine.

• Sonir keeps room measurements on the device.
• Pixmend runs Real-ESRGAN on WebGPU, inside the browser only.
• gpdf builds the PDF inside the calling Go process.

That looks like a privacy stance, but it did not start there. There were two reasons: server costs, and the freedom a product loses once it has a server.

One person cannot keep paying for servers

When the processing happens on a server, the bill grows with every new user, and more so for heavy work like upscaling images or processing audio. I build these alongside a full-time job, on my own. A setup where more users simply means more cost is not one I can keep running for long.

When the processing happens on the device, the user's machine does the computing. However many people use it, my side of the cost barely moves. All I ship is static files.

Paying the bill ends up shaping the product

The bigger cost is not the server bill itself. It is everything you build to recover it.

Processing on a server means rate limits, so nobody burns through it. Counting usage means accounts. Covering the bill means a paid plan. None of these is built for the user; each is built to keep paying for the server. And once they are in, the product starts to take their shape.

Pixmend has no sign-up and no usage limits. That is not generosity: the work happens on your device, so there is simply no reason to limit it. The same is why the Sonir beta can be free.

The freedom stays with the builder too

It is not only the user who keeps that freedom. Without a server, there is no incident response, no data to store, no capacity to plan. The time and attention that frees up goes into the product itself.

On-device processing has its own limits, of course. The compute available depends on the user's machine, and browser and OS rules apply. For Sonir, receiving macOS playback meant building a virtual audio device first (I wrote up how it works on dev.to). Even so, I find that designing within the device's limits gets me closer to what I want to build than designing around recovering costs.

Common questions

Isn't this about privacy?

Your data does stay on your device. But that is a consequence of deciding not to run servers, not the goal. Tidying the reasons up after the fact would misrepresent the actual decision, so I have written them in the order they happened.

Can any product run on the device?

No. A service that only works by pooling many users' data cannot be built without a server. For now, I choose problems that can be solved entirely on one user's device.