Get in touch

Send Us a Message

Straight to the point

No ticket numbers, no chatbots pretending to be human. Fill in the form and a real message goes out โ€” we read every one.

โœ‰ Bug reports & broken links
๐Ÿ’ก Tool ideas & feature requests
๐Ÿ“š Class / board not working well
๐ŸŽธ Just want to say hi
โšก

Fast turnaround

Bug reports on live tools usually get looked at first โ€” broken things get fixed fastest.

๐Ÿงญ

Real feedback shapes real features

Several tools on this site exist because a student described exactly this kind of gap.

๐Ÿ”’

Nothing sold, nothing spammed

Your message is read by the team building the site โ€” see our Privacy Policy for details.

Before you write in

How to Get the Fastest, Most Useful Response

Every message that comes in through this page gets read by the same small team that builds and maintains Back Bencher Class โ€” there's no outsourced support desk skimming through a queue, and there's no auto-reply pretending to understand your issue. That's genuinely useful, because it means a well-described problem can go from "reported" to "fixed" without ever being lost in translation between a support agent and a developer. It also means a vague message takes longer to act on, simply because we have to guess at details a slightly more specific message would have given us up front. A message like "the quiz tool isn't working" is real, but hard to act on quickly. A message like "generating a Class 10 CBSE Physics quiz on Light โ€” Reflection and Refraction gives a JSON error after about 10 seconds" tells us almost everything we need to actually reproduce and fix the problem in one pass. The same logic applies to feature requests: "add more subjects" is a wish, while "the History PYQ tool doesn't handle regional State Board patterns well for Class 12" is something we can genuinely act on.

What Counts as a Bug Report

If a tool generates something clearly wrong โ€” a broken layout, a quiz that won't load, an answer key that doesn't match the questions, a link on any page that leads somewhere it shouldn't โ€” that's a bug, and it's exactly the kind of thing we want to hear about immediately. Include which page you were on, what you typed into the form (class, subject, board, chapter), and roughly what you expected versus what actually happened. If you can, note whether it happened once or every time you tried โ€” that single detail often tells us whether we're looking at a one-off glitch or a real, repeatable issue in the tool itself. We treat broken tools as the highest priority category of message, because a tool that doesn't work isn't just an inconvenience โ€” it's a study session that didn't happen when a student needed it to.

What Counts as a Feature Request

If there's a tool you wish existed, or an existing tool that almost does what you need but not quite, that belongs here too. We built the current six tools โ€” the Study Generator, Scan & Solve, Timetable, Flashcards, Paper Generator, and Daily 10 โ€” because students kept describing gaps that matched exactly those shapes. The next tool on this site, whatever it ends up being, will very likely come from a message that landed in this same form. Being specific helps enormously here too: instead of "make it better for college," something like "add support for semester-based exam patterns instead of just annual boards" gives us something concrete to actually design around.

What Happens After You Send a Message

There's no formal ticketing system behind this form, and that's intentional โ€” it keeps the process honest and direct instead of hiding behind a status-tracking dashboard nobody actually checks. Bug reports on tools that are currently broken get looked at first, since those affect anyone using the site right now. Feature requests get read, considered, and โ€” when they line up with what other students are also describing โ€” folded into whatever gets built next. General feedback, including the messages that are just "hey, this helped, thanks," genuinely gets read too, and honestly, those are some of our favorite messages to receive, because they're the clearest sign the site is doing what it set out to do.

A Note on Response Times

Back Bencher Class is built and maintained by a small team, not a large support operation, so responses won't always be instant โ€” but every message does get read. If something is actively broken and stopping you from studying right now, mention that clearly in your message; urgent, tool-breaking bugs are prioritized over general suggestions. For anything less urgent โ€” an idea, a suggestion, a "this could be better" note โ€” there's no rush on our end either; take your time describing exactly what you mean, since a thoughtful message is more useful to us than a fast one.