Problems we're excited to solve

• 📦 Cross-platform distribution

  Traditionally, developer tools are distributed through OS or programming language-specific package managers. However, as tooling ecosystems grows in size and scope, the desire to support multiple technologies and platforms leads to a need for packaging a single tool multiple times. This work is critical to your end user’s experience, but is really unpleasant and tedious. What if you could outsource it to a dedicated service?

• 🤐 Privacy-first metrics

  Your work as a developer doesn’t end when the CLI is compiled and distributed, that’s just the beginning of the experience for your users. Unfortunately, teams often have very little insight into how their tool is used unless something goes wrong. What if authors could enable opt-in, privacy-preserving, and anonymous usage metrics with a line of code?

• 💡 Cross- and intra-tool discovery

  When tools are language or platform-specific, discovery and reuse becomes much harder. Often tools are discovered through serendipity or word of mouth. Commands and features within tools are often discovered in the same way – the alphabetically ordered man-pages certainly don’t help. What if tools could surface relevant commands or even complementary tools automatically?

• 🎨 Developer-focused product development

  Developer experience is both a very old, and, paradoxically, new, space that is largely measured by what the kids these days call “vibes”. Especially in open source, this leads to “katamari”-style product development, where features are green-lit without consideration for coherence on a larger and longer term scale. As a result, tools that started out simple, grow complex and drive users into a hype cycle of finding the next new thing, not in search of novelty, but usability. What we if we inverted how we thought about tools- instead of focusing on features, focusing on problems to solve- and had that reinforced by our development systems?