When I started building a skill directory for AI agents, the first real decision I had to make wasn't about the data model or the UI framework.
It was: should this be a web app or a desktop app?
I went with the web. Here's why.
The obvious answer isn't always obvious
Most developer tools I use are desktop apps. VS Code, Cursor, Warp, Raycast — they're all native or Electron-based. There's a reason for that: they need deep OS integration, file system access, and low-latency input.
But a skill directory is different. It's fundamentally a browsing and discovery experience. You come in, look around, maybe copy something, and leave. That's a web-native pattern.
Sharing is a first-class feature
The moment I imagined someone finding a useful skill and wanting to share it with a teammate, the answer became clear.
With a web app: copy the URL, paste it, done.
With a desktop app: "Here, download this, install it, open it, then navigate to..."
Sharing is so fundamental to how developer tools spread that making it frictionless isn't a nice-to-have — it's a core feature.
SEO is distribution
I want people to find skills when they search for things like "Claude skill for SQL queries" or "AI agent browser automation."
A web app gets indexed. A desktop app doesn't.
This isn't just about vanity traffic. It's about the discovery loop: someone searches → finds a skill → uses it → shares it → someone else searches. That loop only works if the web can see your content.
The capability gap is closing
The main argument for desktop apps used to be: "You can't do X on the web."
That gap is shrinking fast. Web apps now have:
- File system access (via the File System Access API)
- Clipboard read/write
- Notifications
- Background sync
- WebSockets for real-time updates
For a skill directory, I don't need any of the things that still favor desktop. I don't need to spawn processes, access the registry, or run background daemons.
Maintenance is simpler
With a web app, there's one version. Everyone's always on it.
With a desktop app, you're managing installers, auto-updaters, code signing certificates for Mac and Windows, and users who haven't updated in six months running into bugs you fixed three months ago.
For a side project, that operational overhead is a real cost.
The tradeoff I accepted
Web apps have real limitations. They can't deeply integrate with the local AI agent runtime. They can't watch the file system for skill changes. They can't run as a background service.
For the skill directory specifically, none of those matter. The directory is a read-mostly experience. The actual skill execution happens in the agent runtime, not in the browser.
If I were building the agent runtime itself, I'd probably go desktop. But I'm not — I'm building the place where you discover and share what the runtime can do.
The meta-lesson
The right platform choice depends on what your app actually does, not what category it belongs to.
"Developer tool" doesn't automatically mean "desktop app." Ask what the core interaction is. Ask who needs to share it and how. Ask what distribution channel matters most.
For a skill directory, the answers all pointed to the web.
This is part of a series on building a skill directory for AI agents. The first post covers why I built it in the first place.
Top comments (0)