FeaturePeek lets front-end developers get UI/UX feedback from their team earlier in the release cycle. For every pull request, we spin up a dedicated feature environment with tools like commenting, screenshotting, and bug filing overlaid on top.
Our vision is to fill the void in product development that occurs after developer handoff. Great tools exist for design prototyping (Sketch), design feedback (InVision), developer handoff (Zeplin)... but then there's a cliff, an empty gap, where teams use ad-hoc methods of iteration before shipping. We want to build a tool that shortens feedback loops between cross-functional teams so that the end of the release cycle is sane and stress-free.
If you're familiar with automatic feature environments for pull requests — like what Heroku or Netlify offer — it's like that, but 1) we're platform agnostic, 2) we support Dockerized builds in addition to pure static assets, and 3) we overlay a suite of tools on top of each environment to help your team communicate more effectively.
My co-founder Eric and I wished that this existed at our last startup. While developing a web-based SaaS product, we found that our teammates would wait until the day before the release to leave implementation feedback on new features. The feedback ranged anywhere from CSS nits to the dreadful "This isn't what I meant", in which case we had to decide whether to scramble together a fix or to delay the release. It was tempting to fault the procrastinating reviewers, but it happened so often that we realized it was instead a flaw in the review process. We knew there had to be a better way.
Eric has led Build & Integration teams at Apple and has experience in release management. My background is in front-end engineering and developer experience. So it was natural for us to think in terms of developer tools for release processes, and we decided to work on this together.
There are a few products that exist for gathering website feedback and filing bugs, but they all rely on using a browser extension in a dev/staging environment. This method is inferior because 1) Getting everyone on your team to install a browser extension on every browser is a pain; 2) Code has already been reviewed and merged, which is way too late to start the feedback process. Waiting on code review before conducting feature review is an unnecessary speed bump; and 3) Dev/staging environments can be an integration war zone, especially for larger teams. Another developer's feature could break something in yours, so this environment is not suitable for conducting feature review. QA should still happen on the release as a whole, but the UI/UX review of individual features should occur in isolation.
Here's how it works: After your pull request builds in CI, call our one-liner to ping our services. We use the credentials present in your CI environment to pull your image from your container registry. If you build static content, we download your built assets and add them to an nginx image for you. When the environment is up, a deployment link posts in the pull request, and your team is notified via Slack. We use Kubernetes and Helm to manage and namespace each environment, which spin up and shut down based on VCS webhooks. Our team collaboration features sit on top of your app in a parent frame, so you don't need to install any run-time dependencies to take advantage of them.
All new teams get a two-week free trial — but you can use the coupon code HN2019 to get an additional 50% off your first three months.
We'd love to hear your feedback, and answer any questions you may have :-)
by Andrey
Azimov