Nobody searches for security apps. So I made mine a tool for AI agents instead.

A Japanese version of this is on Note.

(This is Part 2 of the solo-security-dev series. Part 1 on the trust barrier is here.)

In my previous post, I wrote about the trust problem: how an unknown solo dev gets anyone to install a root-privileged Mac security app when they have no brand to hide behind.

I published the security whitepaper, open-sourced the detection logic, built a verify script, and made license activation fully offline using Ed25519 signatures.

At the very end of that article, under "What I still haven't solved," I left this note:

Just being found at all. Unknown, near-zero ad budget. You can build something good and still not get discovered. Separate post.

This is that post. How does an indie developer get a Mac security tool discovered when you can't be on the App Store, you have zero ad budget, and nobody is actively looking for what you built?

The structural curse of security software

With most indie apps — say, a Pomodoro timer or a Markdown notes app — there is a clear discovery path. People search "best Mac timer," or you get featured on the App Store, or you tweet a nice UI screenshot and pick up organic interest.

For a network security app like RoamSwitch, none of those work:

1. You can't get on the Mac App Store. The app dynamically reconfigures the packet filter (pf) and kills sharing daemons when you join an untrusted coffee-shop Wi-Fi. That requires a privileged helper (SMAppService.daemon), which Apple's sandbox rejects.
2. Zero ad budget. Burning thousands of dollars a month on Google Ads or sponsored tweets is out of the question for a project born out of personal curiosity and research.
3. Nobody wakes up and searches for security tools. People don't look for security software proactively. They either install something after getting burned, or their employer forces an MDM profile onto their machine.

Tweeting "Hey, I built an app that automatically tightens your Mac firewall!" produced the expected result: absolute silence.

Trying to reach individual human users through conventional front-door marketing was structurally broken.

Flipping the script: from "sell to humans" to "feed AI agents"

I stopped and looked at what the app actually does.

It sits in the menu bar and continuously evaluates questions like:

• Is the current Wi-Fi network trusted or hostile?
• Did a local dev server accidentally bind to 0.0.0.0, exposing internal ports to the whole coffee shop?
• Is this incoming URL doing suspicious multi-hop redirects or pointing to a known malicious domain?

Then it hit me: The human at the keyboard doesn't want to babysit these questions. But the AI agent sitting next to them in Cursor or Claude Code desperately needs to know.

When an AI coding agent runs in your terminal, it spins up servers, hits local ports, and fetches external URLs autonomously. But the AI has zero sensory awareness of the physical environment. It doesn't know you just hopped onto an insecure airport network, or that vite dev just bound to all interfaces on a public LAN.

What if, instead of asking humans to look at my menu bar UI, I turned the app into the sensory organ for AI agents?

Step 1: Embedding an MCP (Model Context Protocol) Server

I bundled an open-standard MCP server directly inside the app binary.

With a single line in Claude Desktop or Cursor's config, the AI model gains direct access to local security tools:

• get_security_report: Overall posture score and passing/failing audit items.
• get_exposed_ports: List of listening ports exposed beyond localhost, with risk ratings.
• get_guard_status: Active security level (open / balanced / lockdown) and active guards.
• audit_url_safety: Real-time redirect chain expansion and safety scoring for URLs.

Now, when a developer tells Claude, "Start the dev environment for this project," the AI can call get_exposed_ports under the hood and say:

"I started the development server on port 3000, but RoamSwitch reports it bound to 0.0.0.0 on an untrusted public Wi-Fi network. Would you like me to reconfigure it to bind only to 127.0.0.1?"

The app moved from "an annoying alert in the menu bar" to "invisible local infrastructure for AI workflows."

Step 2: Open-sourcing a read-only Swift SDK (RoamSwitchKit)

Next, I extracted the client layer into a standalone Swift package, RoamSwitchKit, and open-sourced it under MIT.

Any Mac utility, status bar tool, or CLI can query RoamSwitch with a few lines of Swift Concurrency:

import RoamSwitchKit

do {
    let client = try RoamSwitchClient()
    let ports = try await client.exposedPorts()
    if !ports.isFirewallShielded {
        // Handle unshielded network state
    }
} catch RoamSwitchClientError.appNotInstalled {
    // Gracefully degrade if the user doesn't have RoamSwitch
}

The architectural rule here was strict: Zero write APIs.

There is intentionally no method to lower security levels, disable guards, or unblock ports. If the SDK had mutation endpoints, it would become an attack vector for other local processes. By making it 100% read-only diagnostic data, integrating it carries zero liability for third-party developers.

I also added an AGENTS.md file to the repository so AI coding tools don't hallucinate non-existent write methods when generating integration code.

Step 3: Publishing the battle scars instead of marketing fluff

If you can't pay for ads, your only currency is primary source knowledge.

Nobody wants to read "Why our security app is great." But engineers love reading about weird edge cases, packet-level breakdowns, and embarrassing development mistakes:

• Packet-capturing coffee-shop Wi-Fi: Breaking down why client isolation fails in practice when attackers use ARP spoofing.
• Fuzzing my own MCP server: How open-sourcing the server made me paranoid enough to run a fuzzer, which promptly uncovered a stack overflow crash inside Apple's own JSONSerialization.
• Zero Telemetry audit: Wiretapping my own app with Wireshark and tcpdump under full lockdown to prove that zero bytes leave the machine.

When you publish deep-dive technical logs, you aren't "marketing." You're documenting real work. And the developers reading those articles think: “Okay, this person isn't cutting corners. Let me try their tool.”

What I've learned so far

1. Offering "parts" has far less friction than offering a "shield"

Asking someone to trust a solo developer's app as their primary security shield is a huge psychological barrier. But offering an MCP tool for Claude, or an open-source Swift package for diagnostics, turns it into a useful component. Developers are much more willing to test-drive a piece of tooling than an all-or-nothing security suite.

2. The gap between "discovered" and "purchased" is wide

Turning the app into AI infrastructure solved the discovery problem. People find the repo, try the MCP server, and read the articles.

However, bridging the gap between "I use the free MCP integration during dev" and "I will pay $19.99 for the standalone Pro automation features" is still a significant hurdle. When you give away the diagnostic tools for free, some users will naturally stop there — and that's the tradeoff of building on open standards.

What is still unresolved

• Reaching non-technical users: The MCP and SDK route works exceptionally well for developers. Reaching designers, freelance writers, or remote workers who work in cafes remains completely unsolved without traditional marketing.
• Global reach: Translating technical articles and reaching Mac communities across Product Hunt, Hacker News, and Indie Hackers is an ongoing effort.
• Optimizing conversion without adding nagware: I refuse to add popups or dark patterns to the free version. Keeping the free tier clean while communicating the value of the paid automation layer is a delicate balance.

Summary

When you can't rely on the App Store and have no money for ads, trying to push a standalone security product is an uphill battle.

The alternative is to open up the interfaces, embed yourself into the tools developers already use every day (like AI agents), and let your engineering transparency do the talking.

It's not an overnight viral hack. But for an indie hacker in the security space, building genuine infrastructure and proving your work is the only sustainable way forward.

The app is RoamSwitch. The Swift SDK is on GitHub (RoamSwitchKit), and the security whitepaper is here.