Hi, thanks for commenting! The idea here is not to skip the code review, but augment it with a way to experiment with the feature as early as possible in the d

Hi, thanks for commenting! The idea here is not to skip the code review, but augment it with a way to experiment with the feature as early as possible in the development process. It’s particularly useful for product owners who may not be coders and want to give feedback on how the feature aligns with the vision. It’s also useful for other developers because seeing the thing live will give more context as to what the feature does and how it behaves, and as such might help reviewing the code and get reviews other than « good to merge » without any meaningful comments. And finally it’s also very useful in making sure every dev can do a little QA on their feature in a standardised environment that runs with non-dev setting, without waiting for a staging server to be available. The 80/20 rule most likely applies here. For some PRs you won’t need preview environments (just don’t add the label), but from my consulting gigs I have experienced more than once the need for this kind of tooling, and also witnessed more than once how many companies try to reinvent their own thing and the time they spend/waste doing so.