Feature requests

Have an idea? Open it as a GitHub Discussion in the Ideas category. We watch the category and promote popular ideas onto the public roadmap.

File a feature request

Open a new Idea on GitHub Discussions →

The link deep-links you straight to the Ideas category with the new-discussion form open.

What makes a good request

A short list, in priority order:

1. The problem you are trying to solve, in one or two sentences. (“I want X” is fine, but “I want X because I am trying to do Y, and right now I have to do Z” is much more actionable.)
2. A concrete use case with a real example from your work.
3. What you have tried as a workaround, if anything.
4. Optional: how you would imagine it working. Mocks or sketches welcome but not required.

Bad requests are the opposite shape: “add ____” with no context. We can do something with those, but we cannot prioritize them well.

What happens after you file

1. We acknowledge with a thumbs up or a comment, usually within a week.
2. If the idea is in scope, we add it to the roadmap’s Considering column.
3. Other users can react to vote and comment with their own use cases.
4. When prioritized, we move it to Planned, then In Progress, then Shipped, with comments at each transition.

If the idea is out of scope (browser support, native mobile, etc.), we comment with the reasoning and close. That does not mean “never”; it means “not in v1.”

Voting on existing requests

Browse the public roadmap and react with thumbs up on items you want. Add your own use case as a comment if it is different from what is already there.

We weight comments more than silent reactions. A thumbs up tells us 100 people want this; 10 specific use-case comments tell us why and how to design it.

Per-customer requests can be private

If you are evaluating Toado for a team and have requests you do not want public, email us at hello@toado.dev or use the contact form. Private feedback gets the same treatment as public, just without the public visibility.

Bug reports vs. feature requests

If you are saying	File it as
”X is broken.”	A bug report (capture with the extension and contact support).
”X works but I want it to work differently.”	A feature request.
”X works but only in case A; case B does not work.”	A bug report (the existing feature is incomplete).
”I want a new thing X.”	A feature request.

Borderline cases: file as whichever fits better; we will recategorize if needed.

Where to next

• Contact for non-public feedback or sales conversations.
• Roadmap to vote on existing items.
• Changelog for what shipped.