I recently built a product called Nightrain and made it profitable. In this post, I would like to introduce Nightrain and share how I built it.

Nightrain is an inbox for GitHub issues. It allows users to view issues and pull requests by latest activities and archive them to keep their inbox ‘zero’. Any new activities on an issue sends it back to the inbox right at the top.

Many software projects rely on GitHub issues to track bugs and feedbacks. But it is difficult to truly stay on top of all the issues. The main cause is that GitHub issue tracker lacks the concept of activities. Instead, the issue tab is chronological at best, showing issues from the newest to the oldest.

Such organization is not suitable for issues because issues are not just records with timestamps. The essence of an issue lies in the dynamic discourse that evolves over time, not in the fact that someone wrote something at some time. Issues are only as valuable to the software teams as the presentation that best captures their progressive nature. And we lack such presentation.

Issues as Email

Nightrain treats issues as though they were emails. In other words, issues are not presented in a timeline but rather in an inbox sorted by their latest activities. If someone on GitHub comments on an issue, Nightrain bumps that issue all the way to the top.

Organizing issues this way has a number of benefits. Most importantly it allows software maintainers to focus on how issues progresses, not on what the issue purports to be. In other words, engineers can put engagement ahead of issue’s mere timestamp. By doing so they can prevent important issues from being buried in an ever-increasing stockpile.

This presentation of issues also breeds responsibility. The inbox shows with clarity which issues have new activities and reminds the maintainers to take action. A maintainer can archive an issue from the inbox after she feels that the latest activity on that issue has been appropriately addressed. Such workflow allows engineers to partake in quicker and more meaningful dialogs with the software users.

Making It Profitable

Nightrain started making money before the first line of code was written. It happened when my former boss sent me an email three months ago:

Hey Sung,

I constantly find all the sites which let you handle Github Issues lacking. None of them let you treat issues like emails, where any new activity needs to be looked at first … . Thought you might be interested in solving this problem.

Rather than rushing to write code, as I have always been wont to do building other things, I sent my former boss the following mockup and persuaded him to pay for the first three months.

Only after acquiring the first paying customer I started building the actual product. Doing so allowed me to gain valuable insight into my customer profile and their propensity to pay. All in all, building with a customer saved me from the usual guesswork and uncertainties that I have always been subjected to as a maker.

Making the Product

I could only spend two hours per day working on Nightrain after returning home from work. And the working version needed to be delivered in one month. From the beginning there was a looming sense of urgency. And the feeling both intimidated and motivated me. By and large, had it not been for that urgency, Nightrain could have never been built.

I was grateful for the pressure because sometimes the most worthy friend is the most vicious foe. For instance, in a heated sparring session, the opponent whom you are trying to take apart suddenly becomes a friend when the bell goes off. When the fight ends with a touch of gloves, I am filled often with grace and respect for the partner. The urgency of the situation created quite similar dynamics.

Every evening for two hours, I sat down in front of my keyboard and worked on Nightrain. After a month I was able to launch the initial version. The following is the final demo that I sent to the customer:

This initial version had the following core features:

  • Sync new activities with GitHub
  • Full-text search over all issues
  • Archive, unarchive, mark as read, mark as unread
  • Reply to issues
  • Inbox view with categories and unread message count

It is a React application that consumes API powered by Go and Postgres. I have been using this stack for all my projects ever since building RemoteBase. It is very solid, performant and most importantly allows me to go from idea to product in a very short time. The only thing different this time is that I put Redis into the mix to implement a job queue because GitHub webhook order is not always guaranteed and can cause race condition.

What’s Next?

As a next step, I will try to spend less time shipping the product. I have learned the hard way that the so-called startup culture that lionizes iteration can be misinterpreted to put iteration ahead of delivering solutions. Quite ironically makers need to ship less to make better products.

Therefore, instead of building features, I would like to spend most of my time talking to other similar teams. Tracking issue is a very common problem in open source teams. With a simple twist of treating issues as emails, they can track issues more closely and ship a better software.

This world is stitched together with open source softwares and we can make the world a better place by improving those projects. Therefore Nightrain aspires to that rather lofty goal of making the world better. Although the idea sounds grandiose I believe that it is worthwhile and the goal it represents certainly attainable.