The app was the easy part. Getting anyone to trust a security tool from a solo dev wasn't.

A Japanese version of this is on Note.

I build a Mac app that automatically tightens your network security when you're on a Wi-Fi you don't trust — coffee shop, airport, conference. The moment you join a network you haven't marked as trusted, it closes the firewall, stops the sharing services, and blocks any dev-server port you left listening on 0.0.0.0. Back on your trusted home or office network, it undoes all of it.

The engineering wasn't hard. Poke pf, listen for network-change events from the OS, stop the sharing daemons with launchctl. I had something working pretty quickly.

The hard part started when I decided to ship it as a product. And it started before "will it sell" — I got stuck one step earlier, at "will anyone actually install this?"

For a security tool, trust is the bottleneck

When I write out what I'm actually asking people to do, it's this:

An unknown individual built a piece of software that includes a root-privileged background process, pitches it as something that will cut off your network traffic, and ships it as a direct download.

Spelled out, even I don't want to install it. And the people with healthy suspicion — the engineers and privacy-minded folks who need this most — are exactly the ones who stop right here.

A product from a big company gets to borrow that company's brand to cover this. A solo dev has none of it. So I ended up having to build every piece of "here's why you can trust this" myself. Here are the walls I hit, what I did about each, and — honestly — what I still haven't solved.

Wall 1: you can't see inside

What I did:

• Published an architecture & security whitepaper. The complete list of operations the privileged helper can perform, how it touches pf, every outbound network path, the crypto, the threat model and the explicit non-goals. Not "trust me" — written at a level you can check against the code.
• Open-sourced the MCP server and the detection logic (MIT). So you can read, in code, exactly what it hands to an AI client and that it sends nothing out.
• Wrote a verify script. A short read-only shell script that checks the signature, notarization, entitlements, and current state against an installed copy.

The funny part: after open-sourcing it I got nervous — people are going to go looking for bugs now — so I fuzzed my own JSON-RPC parser before anyone else could. And immediately hit a crash inside Apple's JSON parser (a stack overflow on deeply-nested JSON objects; try? doesn't catch it — the process just dies). If I hadn't published the code, I probably never would have looked. Fixed in the next release.

Wall 2: distribution economics and the Apple tax

I can't ship on the Mac App Store — the privileged-helper design won't pass review. So it's direct distribution: Developer ID signing, submit to Apple's notary service on every build, staple. That's a $99/year Developer Program membership, and a notarization round-trip on every release.

What I did:

• Collapsed sign → notarize → package → update the appcast → deploy into one script. A manual checklist always drops a step somewhere.
• SMAppService.daemon (registering the helper) won't register unless the app is in /Applications. The first-run "approve this in System Settings" friction is still not fully solved.

Wall 3: the support surface of an app that does things

This app blocks ports and cuts off traffic on its own when conditions are met. Useful — but the flip side is a structural stream of "hey, X stopped working" tickets. Your dev server isn't reachable from your phone anymore, that kind of thing.

What I did:

• Every block ships with a "lift it" button and a reason. After applying, it reads the rules back with pfctl and, if that failed, the modal says so honestly: "traffic is not stopped yet — turn off Wi-Fi now."
• The automatic guards default toward opt-in early on.

Still, as one person, support is basically a 24/7 on-call rotation. That one's a scale problem, not something I can design away.

Wall 4: you can't say "we protect you"

If your security-product copy says "we'll keep you safe," that's a problem both legally and ethically. When ransomware gets through, it becomes "but you said you'd protect me."

What I did:

• The whitepaper and the site both state plainly: one layer of defense-in-depth, not a guarantee.
• "Completely prevents X" is off the table as copy. I actually caught the landing page claiming everything "stays inside a secure sandbox" — the app deliberately doesn't use the App Sandbox, so that was just false. Fixed it, in all ten languages.

Wall 5: pricing a fear product

I didn't want to do the "scare them, charge a premium" thing. But price it too low and it's "isn't free security software kind of suspicious?"

What I did:

• One-time $19.99, no subscription. Aimed at the buy-once crowd who are tired of subscriptions. "A coffee and a snack, once, and it's handled from now on."
• A free tier so people can install it and watch what it does first. The paid value is framed as "it acts for you, no clicks" rather than "it warns you."

Wall 6: Zero Telemetry means I go blind

I decided the app sends nothing externally. That's core to the trust story, non-negotiable. But the cost: no funnel analytics. Where people drop off, which features get used, A/B tests — none of it.

What I did:

• Accepted it. Download counts, checkout, referrers, GitHub stars, article response — run the business on that coarse data.
• Wrote down, explicitly, that "add telemetry" is a lever I'm choosing not to pull.

Wall 7: "what if the developer disappears?"

This is the purchase objection specific to security software. The thing that sits resident and defends you might, one day, stop being maintained.

What I did:

• License activation is fully offline. Ed25519 signature + a device hash, so if the activation server ever goes away, activated Macs keep working.
• Working toward an end-of-life policy (final build stays available, signed, indefinitely). Open-sourcing the key components is part of the same insurance.

What I still haven't solved

• A third-party security review. I test it myself and show my work, but an independent set of eyes hasn't looked yet.
• Just being found at all. Unknown, near-zero ad budget. You can build something good and still not get discovered. Separate post.
• The coarse metrics are here to stay by design.
• Being one person. Response time, sick days, bus factor.

Still

"Won't publishing the code just get you exploited?" — I get the worry, I had it too. But having actually done it: nothing that isn't already in the shipped binary got exposed, and because I expected people to read it, I actually tested the thing properly.

Shipping a security product as an individual is, I think, a job where "building the features" is the smaller half and "assembling the trust" is the bigger one. That's what the barrier really is — and also, it turns out, something a solo dev can do.

---

The app is RoamSwitch. The full design is in the security whitepaper; the open-source MCP server is here.