How to Give Feedback That Earns

I've left over 200 pieces of feedback on VibeCodingList. Over the last 4 months, about 60% of it earns High-Impact. The stuff I wrote in the first few months? One-liners like "cool app, good luck." I thought I was helping. I wasn't.

After a couple hundred reviews, I've figured out what actually moves the needle. Here's what I know.

Actually Use It

People open an app, glance at the homepage, and write feedback. That's not feedback. That's a first impression.

When I tested a Rap Battle Game, I found a credit exploit by ending sessions early, tested multiplayer with two browsers, and actually tried rapping through it (badly). That's how I discovered the scoring was surprisingly accurate. None of that comes from the landing page.

Go end to end. Try it on more than one device. And sometimes, come back days later. I've reviewed products months apart. One visit gives you bugs. Multiple visits give you insights. ## Say What Device You’re Testing On

Easiest thing you can do. Three seconds of typing saves the builder hours of guessing.

"The button doesn't work" is useless. "The submit button stays disabled on Chrome desktop even with text pasted and a vibe selected" — that's reproducible.

When I found a login bug in Tracking, mobile hit a captcha loop while desktop skipped the captcha but still failed. Both sent emails to localhost. If I just wrote "login broken," the builder would've fixed one and assumed both were solved.

Use Bullets. Please.

Turning a paragraph into a to-do list is a pain. You can really help builders out by structuring your feedback so that issues can be easily identified. I use my own notation system:

(>) The action I took or where I was (-) The issue

(--) Sub-details under the relevant issue

($) Feature requests

I don’t always stick to this format but at the very least, I’ll separate the issues with a dash or paragraph break. This makes it easy for a builder to scan it, pull action items, and prioritize. ## Tell the Full Story on Bugs

If you report a bug, commit. Give them what you did, what you expected, what happened, and how reliably it occurs.

I found a search input that would stick after returning to a library — but only on the first few attempts. Couldn't reproduce it after the fourth title. That detail tells the builder it's probably a first-load issue, not a persistent bug.

For visual or multi-step issues, attach evidence. Screen recordings, numbered screenshots. I use Dadan.io — it's free. I've attached media to about a quarter of my reviews. For complex stuff, it's worth the 30 seconds.

Think Beyond Bugs

This is where most feedback stops short. Finding a broken button is useful. Telling a builder their pricing model won't work? That's the stuff they can't get from automated testing.

When I reviewed Authryn, everything worked fine. But I told them 50 cents per receipt was expensive. Hard sell at 10 cents. I'd go in at 5. Suggested ads on create, view, and download instead. For a game called NetWorth, the code was solid but the core loop felt like a spreadsheet — "buy asset, get money, buy more." I suggested market conditions, asset interactions, risk mechanics. That's what takes a game from functional to fun.

You don't need to be a business expert. Just ask: Would I pay for this? Would I come back tomorrow? Who is this actually for. ## Be Honest. Not Mean.

I've told builders their app is "a hard sell." I once said a programming language submission probably wouldn't get useful feedback here because most of us "rely on AI, whole hog, for development."

But I've never told anyone their work is bad.

The trick is pairing the hard truth with context. When I reviewed a document summarizer, I said the system prompt was good — somewhere between Gemini and Manus. Then I said any LLM can do this and the pricing was too high. But I added that I might not be their target market, and for less technical users, the simplicity is a real strength.

"This won't work" is discouraging. "This won't work for me because [reason], but here's who it might work for" is actionable.

And when something impresses you, say what specifically. "Great app" is filler. "The podcast feature is very good — fast, good script, well performed" tells them which investment paid off.

Putting It All Together

A tool review

Tested on Chrome desktop and Android mobile. Generation quality is high and the UI is clear.

• Auto-generation of different angles — front, profile, back, three-quarter.
• Ability to edit an existing generation instead of starting over.

Base is strong. Tighten prompt adherence and add editing, this could compete with the bigger tools.

A game review

Played 4 sessions on Chrome desktop. Fullscreen and windowed.

• Leaderboard — highest score, daily or lifetime. Gives players a goal.
• Single-use power-ups — dash and slow — would add decision-making without breaking the difficulty.

Good base. Once difficulty options are in, this has real replayability.

Same structure, different emphasis. Tools get UX and feature focus. Games get feel, mechanics, and difficulty. Both give the builder a clear path forward.

The Short Version

• Use it end to end. On more than one device if you can.
• State your environment. Chrome. Desktop. Done.
• Bullets, not paragraphs. One issue per line.
• Full bug reports. What you did, expected, got.
• Think like a user, not a tester. Pricing, audience, retention.
• Honest, not cruel. Hard truths with context.

The best feedback isn't the longest. It's the feedback that makes someone open their code editor and fix something.

Be honest, encouraging and thorough. Appreciative builders will make your wallet a little heavier.