Tell us what to build next.

Darvy is shaped by the blind and visually impaired people who use it. Every request, bug, and "this annoyed me" note goes straight to the founder. We read everything and we reply — usually within 24 hours on weekdays.

Quick form — fastest way to reach us

Type what's on your mind below and hit submit. Email is optional — if you give us one, we can reply.

The more specific, the better. Screen reader version, what you said, what happened, what you expected — anything that helps us reproduce.

We won't add you to any list. We just want a way to follow up if needed.

Three ways to send feedback

Pick whichever is easiest for you. The fastest is always email — no form, no login.

Feature request

Something Darvy doesn't do yet that you'd use? Tell us what task it would help with, not how to build it. We'll figure out the implementation.

Email a feature request

Subject line starts with "Feature request:" so we triage it correctly. Add a one-sentence description after the colon.

Bug report

Darvy didn't do what you expected, or did the wrong thing, or crashed? Tell us what you said, what happened, and what you wanted to happen.

Email a bug report

Include your Darvy version (from About) and your OS if you can. We can almost always reproduce from a short description.

Friction / annoyance

Not a missing feature or a bug — just something that took too long, was unclear, or made you give up. These are gold for us. Send them.

Email a friction note

Examples: "I tried to dictate an email but it pasted gibberish." "I couldn't find the tray icon." "It took 30 seconds to start."

Idea / suggestion

Not sure if it's a feature or a bug, just a thought? Send it anyway. We'll figure out the right bucket.

Email an idea

Suggestions about pricing, communication style, install flow, accessibility — anything that affects your experience.

What we do with feedback

  • Read every email within 24 hours on weekdays (often within an hour). The founder reads them personally.
  • Reply with a follow-up question if needed, or a "yes we're doing this" / "here's why we're not" answer.
  • Bug reports → fixed in the next build when reproducible. Critical bugs ship as a patch the same day.
  • Feature requests → public roadmap (coming soon) so you can see what's in flight.
  • We don't ghost. If a request is wrong for Darvy, we'll tell you that clearly, and explain why.

Not feedback — what to use instead