One 1–3 hour interview session closes that gap: a product brief, user flows doc, architecture doc, and 15–50 executable feature specs. Your developer starts Monday. Not “soon.”
Product teams, historically spend a lot of time gathering requirements and then putting together PRDs. I wanted to simplify that process and build a system that interviews someone about a product or a feature of a product and then builds feature specs that could be handed off to engineering team to go build - whether that is humans or AI. This is Visionaire.
It's an adaptive interviewer to understand what you want to build that then filters the idea down into a product brief, user stories, high-level architectural features to support the idea and customer journey, and then feature specs that can be used to build. I also added in a market analysis that is optional if you want to see who the competition is, how big the market is, and if your idea stands out enough from the crowd to be successful.
This is a claude code plugin, so it does require claude code to run.
Report
How do you handle products that need deep technical research, like infra-heavy or ML-driven features where the real spec work happens after the interview?
Report
Maker
@erdi194741 For this, I'd suggest creating an agent research team for this task specifically that is based on what your needs are. After that, there are some options if you wanted to use Visionaire: you can feed the research into visionaire at the beginning, telling it what you want to do and then tell it to read the research your other team did and how you want it part of the app.
That's how I would approach it. The research team will be useful to you for future work, I'd imagine.
Report
Curious how this works for products that already have a partial spec or existing codebase. Do you build on top of what's there or do you essentially redo everything from scratch?
Report
Maker
@ramazanersfoal This works for greenfield projects as well as existing projects. If it is existing, you simply tell it in the interview process that this is for an existing project that lives here: X. The agents will inspect your code base to understand what features exist and how it is written so it can work inside it.
Report
Spent a weekend arguing with a contractor about user flows, so this hit home. Love that the deliverable is something a dev can actually pick up and run with on day one instead of another vague Notion doc.
Report
spent a week writing a brief before and still ended up with vague tickets. one session and the dev actually had something concrete to build from by the end of the call. worth it for the time saved.
Report
love that the output is executable specs rather than a wall of "vision" prose. the "your developer starts monday" framing actually pins the value to something real, not vibes.
Report
No reviews yetBe the first to leave a review for Visionaire — The Spec Is the Product
How do you handle products that need deep technical research, like infra-heavy or ML-driven features where the real spec work happens after the interview?
@erdi194741 For this, I'd suggest creating an agent research team for this task specifically that is based on what your needs are. After that, there are some options if you wanted to use Visionaire: you can feed the research into visionaire at the beginning, telling it what you want to do and then tell it to read the research your other team did and how you want it part of the app.
That's how I would approach it. The research team will be useful to you for future work, I'd imagine.
Curious how this works for products that already have a partial spec or existing codebase. Do you build on top of what's there or do you essentially redo everything from scratch?
@ramazanersfoal This works for greenfield projects as well as existing projects. If it is existing, you simply tell it in the interview process that this is for an existing project that lives here: X. The agents will inspect your code base to understand what features exist and how it is written so it can work inside it.
Spent a weekend arguing with a contractor about user flows, so this hit home. Love that the deliverable is something a dev can actually pick up and run with on day one instead of another vague Notion doc.
spent a week writing a brief before and still ended up with vague tickets. one session and the dev actually had something concrete to build from by the end of the call. worth it for the time saved.
love that the output is executable specs rather than a wall of "vision" prose. the "your developer starts monday" framing actually pins the value to something real, not vibes.