GitHub Developer Story: Abi Noda

We spoke with with Abi Noda (@abi), the creator of Pull Reminders, about how he has grown his project from an idea into a profitable business on the GitHub Marketplace. To learn more, check out his talk at GitHub Universe, October 17 in San Francisco.

Tell us a little bit more about yourself—how did you get started in software tools?

My name is Abi Noda, and I’m an independent developer based out of Chicago.

My first experiences in programming and business were in middle school. I taught myself how to code, so I could build a website for my Counter-Strike team. I learned about sales by hustling modded nerf guns on internet forums. A disgruntled buyer even taught me about customer support by telling on me to my parents when his shipment was delayed.

By my junior year of high school I was on a different track. I was spending half my week practicing flute, so I could get admitted to a top music school. A career in software development wasn’t on my mind but I thought I could use my programming skills one last time to create a web design portfolio that would impress college admissions. They probably wouldn’t have liked my nerf guns.

As I was working on my portfolio I fell in love web design. Saying this makes me feel old, but this was right around the time that CSS was becoming popular. I remember buying the CSS Zen Garden book and staying up late looking all the beautiful designs you could create on the web. I discovered people like Jeffrey Zeldman, Paul Boag, and Jason Fried. I filled my RSS reader with hundreds of blogs on design and software. I was also introduced to the idea that you could make a living building and selling your own software products.

I’d spend hours at the computer lab every day reading blogs and learning about things like Swiss design. My first actual programming book was PHP and MySQL Web Development by Luke Welling and Laura Thomson. I bought the book so I could learn more about backend development and try and land a summer internship after high school.

I was able to land that internship and have been a professional software developer ever since. I’ve worked in different roles ranging from UX design to managing enterprise software teams. I am drawn to work that lets me have transformative experiences while making an impact. My past projects have included helping re-elect Barack Obama, teaching students at Dev Bootcamp, and working in Libya after their revolution to build a voter registration tool for the government.

My ultimate goal has always been to work for myself. I love the process of building products from scratch and seeing them into customers’ hands. I also enjoy the freedom of being able to express myself creatively through my work however I choose. I’ve started a couple businesses in the past but Pull Reminders is by far my most exciting project to date. If there’s one thing my journey has taught me, it’s this: just like there are many paths to becoming a programmer, there are many paths to starting your own business.

Could you introduce Pull Reminders? What does it do?

Pull Reminders helps development teams stay on top of pull requests and complete code reviews in a timely manner. If you’ve ever waited a long time for a code review and had to nag people on your team, you’re familiar with some of the problems Pull Reminders solves.

With Pull Reminders you can set up automated reminders in Slack channels and have everyone receive direct messages about their assignments. Pull Reminders also gives you insight into metrics like review turnaround time and number of reviews completed, helping you recognize contributors and improve your team’s code review process.

More than 400+ companies use Pull Reminders, including Pivotal, Instacart, and Trivago. Open source projects like Cloud Foundry, SaltStack, and Sensu are also on board.

Why did you build pull reminders?

I got the idea for Pull Reminders at my last job as an engineering manager. We had a pretty typical process for code reviews where we’d open pull requests and share them in Slack. I remember one time I asked an engineer on my team about a pull request that had been stale for a couple of days. He told me that he had asked someone for a code review multiple times and had gotten tired of reminding them.

From that point on, I started personally scrolling through all of our pull requests and pinging people on Slack that needed to take action. I hated spending my time this way, but it really helped the team because otherwise pull requests would drag on and take longer to release.

When I left that job I couldn’t shake the idea of building a tool to automate what I had been doing. I was also hesitant because I wasn’t sure if anyone else would want to use it. My side project graveyard was already big enough.

I overcame this fear by doing more research. I asked some of my peers in a “Chicago CTO” Slack group whether they had problems with pull requests dragging on, and a few responded yes. I also looked for existing solutions and found a bunch of “pull request reminder” projects on GitHub that were similar to my idea. This was proof to me that this was not an uncommon problem.

I built the first version of Pull Reminders in a couple of weeks and took it live at the end of January. At this point I had no expectations of making money. I had actually planned on letting people use Pull Reminders for free.

After launch, I started getting a small number of signups through the Slack App Directory. I emailed every user that signed up to find out who they were and what they were hoping to get out of Pull Reminders. A couple of those early users were from larger companies, and I could tell they were taking my product seriously because they asked for lots of changes. I kept making changes based on their feedback until they seemed satisfied. Then I asked if they would be willing to pay. I thought I had about a 30% chance of success, but it worked. Landing those first paying customers proved to me that Pull Reminders could be an actual business.

My next big moment was getting Pull Reminders into GitHub Marketplace back in April. GitHub Marketplace has given me a boost in signups and helped me grow my business without spending a lot of time on marketing.

What has been your favorite feature of the GitHub API?

My favorite feature of the GitHub API is the amazing team behind it. Ivan Žužak and Francis from the Support Team and Steve Winton from Partner Engineering have been incredibly helpful at every step of my journey. I can’t count the number of times they’ve unblocked me.

Many other people from GitHub have supported me along the way, and these small interactions have meant a lot. Knowing that people from GitHub are there to help inspires me to continue building new products on the GitHub Platform. It feels like a true partnership.

What was the most difficult part of integrating Pull Reminders with the GitHub API?

My biggest challenge hasn’t been with the API itself; it’s been figuring out how to support all the different code review workflows teams use on GitHub.

Many teams request code reviews by using review requests. Others use labels, prefixes in titles, or GitHub’s “required reviews” setting to move pull requests through their process.

Things get even more complicated when you factor in the different ways teams organize in Slack. Small teams usually discuss pull requests in one common channel, but teams at larger companies often have their own channels even if repositories are shared.

It’s taken a lot of work to make sure that Pull Reminders works well for these different workflows. I’ve mostly done this by breaking down the different workflows in detail and designing functionality based on that. I also allow teams to customize certain settings, but it’s tricky to offer configurability without making the tool complicated and difficult to use.

Did you work with the new v4 GraphQL API?

When I started building Pull Reminders I chose the v3 REST API because I was not familiar with GraphQL and the v4 GraphQL API did not yet support GitHub Apps. Fast-forward to today and both of these things have changed. I am keeping an eye out for opportunities where the v4 GraphQL API may be useful.

What are the biggest challenges you’ve faced and obstacles you overcame?

As the only founder it can be difficult to stay positive and motivated. When you invest so much of yourself into creating something it can be scary to risk rejection and release it into the world. Sometimes I get down about unimportant things. For example, if I have one week where my signups dip or a customer I admire doesn’t purchase a subscription, I start to get negative thoughts. It feels silly because my business is growing well and I feel lucky to be in the position I am.

Another problem I have is being a perfectionist. It’s easy for me to go down rabbit holes and labor over details that aren’t practically benefiting my business. I’ve had to stop myself from wasting time overly refactoring code or redesigning something that looks good enough.

Being a perfectionist can really backfire because when you start over-scrutinizing your work, you often end up making it worse. When I was working on my responses for this interview I started wordsmithing things to the point where I was making it longer and more boring. I had my brother and a couple of my friends rescue me by proofreading and telling me to stop.

What are your plans for the future?

Right now I am working on a new GitHub App. I’ve found that there’s growing interest amongst engineering leaders to use data derived from GitHub activity to inform decisions and improve performance. I’m working on a new product called “Dev Insights” that’s aimed at solving this. For example, it will allow organizations to set code review turnaround time SLA’s by team or repository, then track how well they are doing at meeting their goals both as an organization and individually.

In addition to building stuff, I also want to help other developers. Many developers I know want to have their own business that they can eventually work on full time. My journey has had many twists and turns and one thing I haven’t talked about is all the people that have helped me along the way. I’d be happy to answer questions from any readers that are going down a similar path. I’m also working on a new blog where I’ll share what I’ve learned and create guides on everything from incorporating and taxes to sales and customer support.

We hope you enjoyed our interview with Abi Noda (@abi). If you’re interested in building your first GitHub App, get started with our quickstart guide. Or find Pull Reminders—and dozens of other GitHub Apps—on GitHub Marketplace.

Written by

Brian Douglas

@bdougie