When I started building Roadwise, I had a fairly normal idea. I wanted one place where developers could collect feedback for all their projects. Users would submit requests, vote on them, follow the roadmap, and get an update when something shipped.

At first, I treated it as a UI problem. The board had to be easy to use, and the dashboard had to show which requests people cared about.

Then coding agents became a normal part of my work. An agent could inspect a repository and implement a feature, but it knew nothing about the people who requested it. I still had to open Roadwise, copy the request into the conversation, and return later to update its status. It made me think about all the other places where software should be available outside its main interface.

The UI Is One Client

Roadwise still needs a good interface. People want to browse a roadmap, vote on ideas, and see what changed without talking to an AI assistant.

It also has to work where the work already happens: in a terminal, an automation, a coding agent, or a feature on someone's phone. The dashboard is one client of the same system.

One System, Several Interfaces

A documented REST API is the base. By open, I mean that customers can access it with normal authentication and understand it from an OpenAPI schema. It does not mean exposing data anonymously.

For Roadwise, the API gives access to requests, votes, comments, and statuses. The CLI calls the same endpoints, so a developer can manage feedback without leaving the terminal. It also works in scripts without adding another SDK.

MCP adds a smaller interface for agents. A tool can find open requests, add an internal note, or change a status. The agent sees a few clear actions instead of every endpoint in the API.

A plugin is useful when people want Roadwise inside ChatGPT, Codex, or another platform. The current OpenAI plugin model can package instructions, an MCP server, and optional UI. I see this as another way to distribute the same tools, not a separate version of Roadwise.

Native apps are another route in. On iOS, App Intents can make actions available in Siri and Shortcuts. A share extension could turn selected text from another app into feedback, while a widget could show unresolved requests.

Each of these paths should use the same requests, projects, and permissions as the dashboard and API.

The Boring Parts Are Shared

Every interface needs the same boring rules. Authentication should have narrow scopes. Writes should be idempotent when retries are possible. Errors should explain what failed and what input was expected. Actions should leave an audit trail, and webhooks should report changes without constant polling.

Agents expose problems with these details sooner. They retry requests, send incomplete input, and sometimes misunderstand a tool. A vague error that annoys a developer can leave an agent repeating the same broken request five times.

Bringing Feedback into the Work

I want a developer to ask an agent which requests relate to the current part of a codebase. The agent should bring those requests into context, help compare similar feedback, and update Roadwise after the work ships.

Roadwise already exposes feedback through a REST API, CLI, and MCP. I now think about where a feature should be available whenever I add it, instead of stopping at the dashboard screen.

If you maintain several projects and your feedback is spread across GitHub, messages, and random notes, Roadwise is my attempt to put it in one place and make it available wherever the work happens.