// build note 01

Storage you can actually own.

Why I skipped the NAS, trusted my family's data to a filesystem most people have never heard of, and built the GUI that OpenZFS on the Mac never had.

FREE macOS ZFS Manager · 1+ year in production · macoszfs.contextinit.com
Download free FREE
fig. 01

The itch: I didn't want a NAS

When I set out to build proper storage for my home lab, every guide on the internet pointed the same direction: buy a NAS. I kept resisting, for two reasons that felt obvious to me and apparently to nobody else.

First, I didn't need network storage. My data lives next to one machine. Paying for an always-on network appliance — with its own CPU, its own RAM, its own power draw — to serve files across a network I wasn't going to use felt like buying a delivery truck to move groceries from the kitchen to the dining table.

Second, and more important: a NAS operating system is another moving part that can fail. It's one more vendor to depend on, one more update cycle to manage, one more thing standing between me and my own files. The whole point of this project was independence.

So I went the other way: a simple DAS enclosure, hard drives I chose and bought myself, plugged directly into my Mac. No appliance, no appliance OS, no lock-in. Just drives I own, attached to a computer I own.

fig. 02

The catch: macOS doesn't do redundancy

One requirement was non-negotiable: a RAID-5-style setup — one drive's worth of redundancy, so a single drive failure is an inconvenience instead of a catastrophe. macOS simply doesn't offer that natively.

That gap led me down the OpenZFS rabbit hole, and what I found there changed the shape of the project. ZFS isn't a hobbyist filesystem — it's the storage layer trusted in mission-critical deployments around the world: RAID-Z redundancy, end-to-end checksumming that detects silent data corruption, instant snapshots, self-healing scrubs. It was everything I wanted, already battle-tested for decades.

The best storage technology on the planet was free, open, and sitting right there. The only thing keeping ordinary people away from it was a command line.

That's not a technology gap. That's a product gap.

fig. 03

The build: a menu bar, not a manual

I built a native macOS menu-bar app that does two jobs. It sets up the entire infrastructure — taking you from bare drives to a healthy RAID-Z pool without touching a terminal. And it keeps it managed: pool status, snapshots, and scrub health, glanceable from the menu bar where storage tooling actually belongs.

The product thesis was translation, not invention. ZFS already had the substance; what it lacked was an interface that turned expert concepts — pools, vdevs, scrubs — into something you can read in two seconds while your coffee brews. Every design decision flowed from one test: would someone who fears the terminal trust this?

[ menu bar screenshot — to be added ]
fig. 04

The decisions that mattered

Independence as the spec. No cloud account, no subscription, no vendor telemetry. Your pool works the same whether my domain exists or not. That ruled out a lot of convenient architecture — and made the product honest.

Secure remote access, the self-run way. The moment you own storage, you want to reach it from outside your network. The conventional answer is a vendor cloud relay or — worse — open ports. The answer I built around: self-run VPN tunnels like Tailscale and WireGuard. You get your data from anywhere; nobody else gets a copy of the keys.

DECISION — WHY FREE, NO STRINGS

A tool whose entire pitch is "own your storage, depend on nobody" can't ship with a dependency on me built in. Free, no account, no upsell — anything else would contradict the product on day one.

fig. 05

Results: the honest version

I haven't marketed this. No launch post, no download counter worth quoting. What I have instead is the metric I actually care about: this app has been the storage layer under my own home for over a year. Every family photo, every backup, every byte I'd genuinely grieve — sitting on a pool this app set up and monitors every day.

Dogfooding isn't a development practice here; it's the proof. If it can't survive my house, it doesn't ship.

build-sheet
problemredundant local storage, no NAS, no lock-in
betZFS lacked a product, not capability
form_factornative macOS menu-bar app
pricingfree — independence can't have a toll
remote_accessself-run tunnels (Tailscale / WireGuard)
proof1+ year running my own home, daily
fig. 06

What I'd tell you

The biggest lesson wasn't technical. It's that the gap between great technology and everyday people is almost always an interface problem — and closing it is product work: deciding what to hide, what to surface, and what "trustworthy" looks like at a glance. ZFS didn't need a better filesystem. It needed someone to care about the two seconds a normal person spends deciding whether to trust it.

// build note 01 of 02 next: the agent that renegotiated my insurance
Download free FREE