How to get client feedback on an app or prototype, without screenshots
Annotated screenshots, long email threads, demo calls. How to collect a client’s feedback on the app you are building, right on the real app.

You are building an app for a client. A new version is ready and you need their opinion. Most of the time it goes like this: a few screenshots in an email, or a demo over a video call, then a list of feedback that arrives three days later, in a separate document, with sentences like “the button at the top right, on the second page”.
It works, more or less. But every step loses something.
What screenshots and demos don’t show
A screenshot shows one moment. Your client sees a frozen screen: not the menu that opens, not the form showing an error, not the page on their phone. They comment on what they were shown, not on what they would have found by trying.
A demo goes at your pace. On a call, you do the clicking. The client discovers the app through your path, and whatever would have made them hesitate on their own goes unnoticed.
Feedback lands far from what it is about. “The text under the title is too long”: which one, on which page, in which version? You have to find the element, guess, sometimes ask again. And when the next version ships, nobody knows which feedback was handled.
What makes a client review work
A good review comes down to a few simple principles:
- The client tries the real app, not a picture of it. They click, fill in, navigate, on their computer or their phone.
- Nothing to install, no account to create. Every extra step is a client putting the review off until later.
- Each piece of feedback is attached to what it is about: this button, this text, this image. No need to describe where it is.
- They know what to look at. A client told “look at the sign-up, then the payment page” gives more useful feedback than one dropped into the whole app.
- Feedback has an end. Each remark can get a reply, be decided on, then resolved.
- One link, from one version to the next. The client keeps the same link, and the feedback history stays in one place.
How to do it with Riqoch
That is exactly what we built Riqoch for. It is a Mac and Windows app that runs the app you are building and publishes it as a review link.
- You launch your app from a folder on your computer or a GitHub repository. Riqoch works out how to run it and installs the dependencies: Vite, Next.js, Nuxt, Astro, SvelteKit, Angular and most JavaScript projects, as well as Django, Flask, Rails or PHP. Nothing to deploy.
- You map out the path: which screens to look at, and in which order. The client knows where to look.
- You publish the link and send it. The client opens it in their browser, on a computer or a phone, with no account and nothing to install.
- They comment right on the app: one click on a button, a text or an image, and the comment sticks to it. You reply in the thread, and the comment is resolved once it is handled.
- The same link follows every version. You publish again, the client finds the new version in the same place, with the history of their feedback. You can name versions to keep track.
For a confidential project, a review can be protected with a password. And if your team lives in Slack, each comment thread can be sent there: replies written in Slack come back to the review.
What about a prototype?
It depends on what you call a prototype. For a mockup or an early idea, design and prototyping tools do the job very well. As soon as the prototype is running code, however rough, even built in an afternoon with an AI, that is what you should have reviewed: the layout, the states and the real content are already there, and they are what your client will actually use.
In short
For a client’s feedback to be useful, give them the real app, with nothing in the way of opening it, and let their remarks stick to what they are about. The rest, keeping track of replies and versions, follows from there.
Download Riqoch to get your next version reviewed.