Une demande de relecture sur une version Replit commence en général par une question précise : est-ce que la chose demandée fonctionne réellement. Un relecteur, qu'il s'agisse d'un responsable, d'un client ou d'un coéquipier chargé d'une passation, veut rarement une visite complète de l'application. Il veut voir le parcours précis qu'il a demandé, terminé, avec un résultat qu'il peut comparer à sa demande. Une vidéo de présentation guidée construite pour cet usage doit répondre à cette seule question, puis s'arrêter.
C'est un exercice différent d'une démo construite pour vendre l'application ou la mettre en valeur. Une relecture guidée ressemble davantage à une preuve qu'à du marketing. Elle doit correspondre précisément à la demande, montrer le repl réellement en cours d'exécution plutôt qu'une version simulée, et éviter de laisser entendre que toute l'application est terminée alors qu'un seul parcours a été relu. La structure de Replit, où le code et le webview en cours d'exécution se trouvent côte à côte, facilite cette préparation, à condition que le repl soit public et actif avant qu'un rendu ne soit demandé.
Cette distinction compte parce qu'une relecture qui va trop loin peut coûter plus de confiance qu'une relecture qui sous-estime le travail. Si un développeur envoie une présentation guidée qui inclut discrètement un écran sans rapport à côté du parcours demandé, un relecteur attentif peut commencer à se demander ce qui a encore été passé sous silence. Une présentation guidée qui s'en tient exactement à ce qui a été demandé, même si cela donne une vidéo plus courte que ce que le développeur préférerait envoyer, apparaît comme plus crédible précisément parce qu'elle ne cherche pas à faire plus que ce qu'elle peut prouver.