About
Near-field. Far-field.
I build on the near side.
Everything Nearfield builds starts on-device, by default. I'm a PhD engineer building these apps solo — in public, on-device, and on purpose.
The name
Near-field, not far-field.
Near-field and far-field are real terms in the physics I work in day to day — and they describe exactly what I'm building. Nearfield keeps computation near you, on the device, by default — instead of routing it far to a server first. The name states the promise instead of encoding it in a symbol only I can decode.
Concretely: no accounts, no tracking, on-device by default. Processing runs locally unless a feature genuinely needs a server — and when that's true, it's stated plainly.
The promise
Nothing goes to servers I run — unless a feature genuinely needs it.
No accounts, no tracking, no telemetry. Here's the honest, per-app version of what reaches a server — and what never does.
By default, there's no server in the way.
And I'd rather tell you the exceptions than claim otherwise.
Meditor
Publishes to Medium and uploads images to your configured host — because that's what publishing means. Its statistics stay local and numeric-only.
PhaseWake
Sleep detection runs on-device; health data is read from HealthKit, never uploaded. A wellness tool, not a medical device.
GeoPunch
Your shift data stays on your phone; the address search sends the text you type to an online geocoder.
If an app needs to reach a server to do its job, that's stated on its page. Nothing here is telemetry.
The person
Built solo, in public.
I'm a PhD engineer who works in numerical simulation and physics day to day. I build these apps to put that discipline to work on everyday problems — writing, sleeping, work time — and to do it in the open.
The process is posted as it happens: the builds, the failures, the launches. Follow along and you'll see the next one before it ships.