Would you recommend this product?
15 Reviews5.0/5
Hello hunters! Very excited to share PullRequest with the community today. The idea came from a very real need within the engineer teams I’ve worked with over the past 15+ years. We’re headed into demo day on Monday at YCombinator. It’s a bit of a crazy time, so apologies if I’m a bit slow to answer questions. Because we love ProductHunt so much, feel free to drop me a line at lyal @ our domain name, and I'll be happy to give you a free month of static analysis / linting platform when our general release comes available. Some answers to common questions: 1) How can reviewers gain enough context to be valuable? We assign reviewers to the same projects repeatedly, so they gain insight into the projects they are working on. For enterprise teams, we ramp reviewers up on the code base over a defined period before letting them lose on the review flow. Finally, we’re building some great tech that breaks up projects and highlights key components for initial review. 2) How can my code be safe? We’re using a 3-way innovation assignment/NDA that protects your code as if the reviewer was a direct contractor with your organization. We do background checks on all reviewers, and we’re limiting reviewers to markets where we have a presence for now. 3) This can’t be as good as an in-house review? We layer on the same kind of feedback that internal reviews do. From architecture to security to language issues to technical debt, we're working on providing a solution that improves code quality across the board. More than anything, if I can help organizations move more product (and have happier engineers), I look at PullRequest as an unmitigated success. For many teams with a strong code review process, we absolutely think a significant gain is code communication and group problem solving. Here, we like to think of ourselves as a great option for security and second-eyes reviews. For other orgs, code review can be a political, stressful, speed-killing process that’s the spinach of development – necessary to be healthy, but people hate it. We think we’re a great option to help ease the pain here. Finally, more teams than we’d like to think don’t do any code review at all (60% of teams by some surveys!) 4) $49? That’s way too expensive! || $49? That’s way too cheap! Our pricing page is a work in progress. Right now we want to capture the fact that we’re looking to work with customers of all sizes – from the individual to enterprise. Because we have real, human labor one one side of the equation, we have to make sure we’re charging enough to support them. On the other hand, we want to make this accessible pricing wise to anyone who could use it (as we’re really passionate about improving code quality). Pricing is based on volume (both the number of reviews and how complex each review is).
Upvote (20)Share
@lyal Awesome product. Good luck on Demo day! 👊💩
@lyal Great idea, Kinda one of those #palmsmack services, I'm sure you'll kill it.
@lyal totally amazing. $49 is way too cheap :).
This approach is interesting, but it seems to indicate code reviews are only time consuming and add little value. In my experience, the opposite is true: teams learn a lot from reviewing each other code. They learn new technology, new ways of approaching a problem, they understand part of the code they don't work with on a daily basis, they have a bigger feeling of ownership etc. This being said, a use case is interesting: having code reviewed in a technology or a language no one in a company is an expert in could help developers have valuable feedback and ramp up faster. I'm wondering what kind of feedback is given by reviewers? Is it only about functioning code or are the overall code architecture and technical decisions challenged?
@gflandre Great minds - that was half of the inspiration for creating the product! No developer should be an island, yet many of us end up supporting a silo'd codebase in an organization. The other case that really hit me was when a colleague went on vacation, I watched a pull request languish for 2 weeks until they got back, waiting for a review. What a speed killer! We give both kinds of feedback.
@lyal Great stuff, thanks for clarifying!
How it works: 1 Submit Code Ready for a review? Have all pull requests looked at, or add @prbot to your title to schedule a review, from within your version control. 2 Static Tools Run We run concurrently optimized static analysis and linters, all customized for your team's needs. We'll even try to set defaults based on your previous pull request histories. 3 Expert Reviews Code An expert reviewer is assigned to your pull request. They look through the static and linting outputs, generating a pull request for easy fixes, comments and questions for hard ones. 4 Changes Approved / Discussed Have questions? Confused about one of our proposals? Not a problem! Comment right in GitHub, Slack or our web application. Once everything looks hunky-dory, you push away using your normal CI/CD process. 5 Happy Code, Happy Product We'll help you move faster and catch more issues. This leads to a happier team, a happier product, and makes us happy too!
How do you ensure the privacy of the code?
@andyfang98 We don't have our reviewers check the code out (it lives within a review environment). We also sign an NDA and PIA with all reviewers to ensure privacy.
This actually seems really useful for someone like myself who is hiring freelancers to develop an app for me. I have no way of checking the quality besides just running tests, so this is something I would look into.