If a product is meant for technical people who already work in agent-native tools, setup should not begin by pulling them into another dashboard.
That was one of the product decisions I cared about most with Explore.
Too many tools still claim to fit modern technical workflows, but the first real step is the same old pattern: open a browser-heavy onboarding flow, click through a few pages, and only then get back to the environment where you actually work. It adds friction at exactly the moment when a product is supposed to prove it understands its user.
I did not want Explore to work like that.
I wanted the setup flow to stay where technical people already are. In the terminal. In the agent. In the workflow they are already using.
That is why the path is simple:
- install the CLI
- run explore setup
- use the browser only when signup, sign-in, or approval is actually needed
- go back to your agent
- publish a live profile
That order is deliberate.
The browser still matters. There are things it should own. Signup, sign-in, approval, and a few account-level actions belong there. But that should be the supporting handoff, not the main stage.
The main stage should be the real workflow.
That matters more now because technical users are getting less patient with products that pretend to be agent-friendly while forcing everything important back into a dashboard. If the product says it fits how modern technical people work, the setup flow should prove it immediately.
Explore is my attempt to do that more honestly.
The goal was not just to make profile setup possible. The goal was to make the first useful result feel fast and native to the way technical people already work: bring in your material, run setup, handle approval only when needed, get back to the agent, and end up with something live.
Watch the 2-minute walkthrough and see how quickly you can turn a static CV into a live profile: