1
0 Comments

I launched my developer CLI, got 13 votes — and learned that interest is not activation

Last week I launched Archseed on Peerlist Launchpad.

It received 13 votes and finished around #58. That was encouraging for a first launch, but the more useful signal came after people visited the website.

Some developers were interested in the idea, but very few actually tried the CLI.

After looking at the landing page, the problem was obvious: it explained the architecture-first idea, but it did not make the first action clear enough.

A visitor had to understand the product, find the docs, discover the install command, and decide whether to try it. That is too much friction for a CLI beta.

So I updated the landing page around one simple path:

```bash

npm install -g @archseed/cli

archseed init

```

The page now shows installation immediately, explains what the CLI creates inside the repository, and makes it clearer that Archseed works alongside Cursor, Claude Code, Codex, Gemini CLI, OpenCode, or another coding agent.

I also narrowed the current focus:

> TypeScript + Next.js developers building with AI coding agents.

I originally thought the next priority was pricing and conversion.

Now I think the priority is simpler: get a few developers to complete one real workflow, understand where they get stuck, and learn whether the generated project context actually changes what they ask their coding agent to build.

For now, I’m looking for feedback, not trying to optimize pricing.

If you build with AI coding agents, I would really value one direct answer:

What would stop you from trying a new CLI on an upcoming project or feature?

- installation friction

- unclear output/value

- lack of a real project to test it on

- trust/privacy concerns

- something else

Archseed: https://www.archseed.co/

posted toAvatar for product ArchSeed
ArchSeed