Part 1: Launch, Pivot, and how the Code Review Service was developed.
When you have a product that you want to create and give your 100%, starting your own business is an option. As an engineer who took that path, I’d like to tell you my success and failure stories by sharing with you why I founded Sider and where we are now and beyond. I’d be happy if my story can help people: engineers who are interested in starting their businesses, people who want to know about the life of CEOs, and people who want to take a break from technical topics. With my company, Sider, being one of the sponsors of this fall’s GitHub Universe for the first time as an opportunity to look back, I will tell you from the time when I was coding by myself to when I stopped coding and became the CEO to lead an organization for the following three weeks. In this first post of the series, I will talk about starting businesses to establishing a code review service. I will write about Sider’s history in the following post and what I learned through my successes and failures in the final post.
First, for the people who don’t know me, let me quickly introduce myself and my professional background.
My name is Koichiro Sumi, and I’m the CEO of a code review automation service, Sider. I am on Twitter and GitHub as sumyapp. Being a programmer initially, I started coding professionally through developing iOS apps for iPhone 3Gs in 2009. I began coding Rails when developing the server-side applications for iOS apps and my thesis project around 2010. I think the version of Ruby on Rails I used for the first time was 2.3.
Regarding my career background, I had created many iOS/Android/web apps as a freelancer since 2009 when I was still a student. In 2010, I started working for Rakuten, Inc. where Yukihiro “Matz” Matsumoto was its technical advisor. From 2011, I have worked on new projects for clients such as CyberAgent (Applibot) and Digital Advertising Consortium (DAC). I did everything from planning to development to the server maintenance and operation. After that, I founded ActCat, Inc. After going through name changes twice, it is now operating as Sider, Inc.
What is Sider?
Sider is a web service which supports code review for engineers. Sider works with GitHub, analyzes the code when a pull request is created, finds various issues, and notifies them on GitHub. As a result, Sider can save the time of engineers reviewing the code by detecting problems before they do.
Sider is a developer-focused service launched in Japan, and the service is available worldwide through our website and GitHub Marketplace. Engineers in various countries such as the United States, India, Switzerland, Iceland, and Vietnam use Sider as a service that eases and improves code reviews. As we are expanding our business to overseas more and more, Sider will be participating in GitHub Universe in San Francisco this coming October as one of the sponsors. If you are at GitHub Universe, please visit our booth!
Sider and Ruby on Rails
Sider is developed on Ruby on Rails. The version used for the first commit was 4.0.1rc3.
Sider has been sponsoring RubyKaigi from 2016 to 2018 consecutively, and a couple of our staff have spoken at RubyKaigi in 2017 and 2018. So, Sider has been working closely with the Ruby community. Also, the most popular framework among Sider clients is Ruby on Rails. I hope Sider will continue to provide services that can support Rails developers.
The reason why I decided to write these blog articles is that it has been four years since Sider started providing its services in 2014 and I have something to talk about. As I transitioned from writing code to managing a business, with mixed feelings of excitement and nostalgia, I can talk about what I’ve been through. Not to brag, I had a couple successes and more failures. By reflecting on Sider’s successes and failures so far, I would like to continue to improve Sider to become a service that is used all over the world.
Those who want to remain as or want to become developers might not find this post helpful, but I hope you will enjoy reading it. For developers who are interested in starting their own business, I believe and hope this article includes helpful tips. If you have any questions, please don’t hesitate to ask. Maybe, some readers might not be happy with their CEOs. If you can see the life of a CEO and have more understanding of its role and nature from this post and be patient with your CEO, I’d be happy.
Let’s get started with my journey to entrepreneurship!
The Journey to Entrepreneurship!
In this section, I’m going to write about how I became an entrepreneur from a software developer and what I’ve experienced since I launched my own business.
First of all, why did I start my own business? The advantage of starting your own business is that you are not constricted by the company.
I like making new things with my own hands. I love “making things” more than programming itself. I also like nurturing what I make.
When I was helping companies launching new projects at my previous work, I felt there were many constraints that I couldn’t do much about: budget, human resource (e.g. working with a specific person within the company, ordering through a particular company, etc.), project themes, and timeframe (the management decides the timing of a new project launch). Because these constraints are critical factors for a successful project, Failing just one of such constraints could give the team a huge impact that could make the new project fail.
To create what I want and while keeping those constraints at a minimum, starting my own business, which let me control as much as I could, was a good choice.
Pivot, Pivot, Pivot
The below is the list of products I released in the past. I will talk about them in this order.
- Onegai Company, 2012 (Already Sold)
- A haircut model matching app, 2012 (Already Sold)
- Repeat developing prototypes and scratching them off & commission work
- StudyTech/Spath School, 2013
Onegai Company, 2012 (Already Sold )
The reason why I started my own business was that I wanted to create something new with my own hands without dealing with constraints and make it grow. So, I didn’t have a clear idea of what I really wanted to create then.
So, the first service was similar to Quora but with a point system. Even though I don’t want to talk about the name of the app, it is called “Onegai Company: the Q&A app that you can get points for your answers.” Onegai means please or favor in Japanese.
As a side note, this app was built on Ruby on Rails.
On iOS and Android, the app displayed the web contents in native app frames, so it was all WebView other than the push notification feature. There was nothing complicated technically. The languages used for the technology stack are Ruby on Rails, HTML, CSS, jQuery, Objective-C, Android Java, etc. The server-side was simply structured with Heroku and MySQL (Heroku add-on).
Around 2012, there were many websites and apps that offer reward point service in Japan. But it was hard to accumulate points because the advertisers were the same on those services. Having more advertisers was necessary to increase the point currency. But the number of advertisers was limited. So, I came up with a strategy to increase the volume of point currency by letting individuals be advertisers.
Generally, when you ask a question on a popular website such as Quora, it takes a while to get answers, and you get only a few answers. But, on Onegai Company, rewarding points for answering questions encouraged people to answer. The app eventually generated a few hundred responses in one hour.
At the time of developing the app, I expected these types of users for the app.
- People who want to earn reward points
- People who want answers
- People who want to interact on the internet
We invested about three million yen in pre-launch advertisements, and the app had tens of thousands of users in just about one week from its launch. But the number of active users quickly went down to a thousand. Even though we had new sign-ups, the number of active users went back to around a thousand and never went below a thousand, which I didn’t quite understand. So, I decided to sell this app.
I assume something like the below happened.
Haircut Model Matching App, 2012 (Business ownership transferred)
This app is still offering its service now.
The app matches hairstylists who are seeking haircut models and people who want a haircut for free.
I started this service because I wanted to create a startup that solves a problem. I got the business idea when I thought it was extremely tiresome for hairstylists to find haircut models. In Tokyo, I see many hairstylists who are looking for models to practice cutting hair. There must be many people who would want to get a haircut for free, so I thought about matching them with hairstylists. Then, I did hearing sessions with stylists and found out that stylists need to fill the quota of 100 or 200 models. Some had to look for models until the last train of the day. I found their problem to be severe, so I decided to provide the service. I participated in the TechCrunch Tokyo Startup Battle at the time of the app release.
Well, after I released the app, I found out that the practice of finding haircut models is limited to Tokyo and other big cities. My sister-in-law who is a hair stylist told me this kind of custom doesn’t exist in other suburban cities.
The market for haircut model matching is small because the practice was limited to Tokyo, so monetization of the app was difficult. Also, there was a substantial number of competitors. It seemed extremely challenging for my company to continue working on this service. So, I decided to sell the business again.
Days of making and scrapping prototypes & commission work, 2012–2013
During this period, I came up with various ideas, did hearings, and even made prototypes for some of them. But after debating myself whether there are stable markets for the products, there are apparent issues, or I want to work on them, all the projects were scrapped.
Meanwhile, I had revenue from commision work. I am still grateful to my clients who gave me work at the time.
Here, I will show you one of the prototypes that never saw the light of the day. The below is a prototype for digital signage ad network which can measure the performance of ads. By connecting an iPhone and a display and showing a video ad, the system can calculate the time/duration and the number of people who watched the ad from the face recognition technology. Conventional signage ads had problems such as unable to measure the effect and taking a long time to change (replace) ads. This system tried to achieve the measurement of ad performance, real-time ad delivery, and signage ad network.
When I think about this now, it seems not a bad idea. But when I did hearings at the time, I found out that there was no need for measuring the ad performance among the owners of ad locations and ad campaign marketers in the first place, so I decided not to move on with the project.
StudyTech / Spath School, 2013
Seeing the high risk of consumer apps and understanding my passion for doing something helpful for people led me to open an online programming school in 2013.
Then, Progate didn’t exist yet, and Codecademy just raised the Series B fund (US$1.25 mil). As a programming school in Japan, it was a relatively early entry in the market.
In those days, existing programming schools had the following issues: there were many programming schools, but their learning resources were textbooks and not engineers teaching real-life programming, and going to a programming school doesn’t mean you get to develop things but learn from books.
In response to the issues, I launched the service to provide classes taught by engineers and let students develop and make things.
After I launched the service, I observed the challenges below.
- 90% of people who bought courses don’t start studying.
- The other 10% can get to the level of developing such as websites and apps, but it takes time and effort to go beyond the beginner’s level.
- Reviewing code every day was exhausting.
In the end, the service followed a marketing business model that uses the revenue generated from people who don’t start learning after purchase to target more users. I didn’t like the business model, and because of the above issues, so I decided to withdraw from the business.
Of course, I could have gotten new users through word-of-mouth instead of ads. But that would take a long time to see the results. Also, I assumed that the percentage of people who don’t learn after purchase wouldn’t change, so I made a final decision to leave this business.
Lost in life and a turning point
I had created products many times and experienced business transfer and withdrawal. Around November 2013, I had to reconsider what to do next while thinking about closing down my company. But I couldn’t come up with a solution alone, so I asked experienced entrepreneurs for advice.
When I talked with five entrepreneurs, strangely, all of them suggested traveling.
So, I decided to go to San Francisco by myself as a self-searching journey.
Searching Myself on the US Trip
In December 2013, while traveling San Francisco, I asked myself what I wanted to do. Also, I looked back on things that I’ve spent much of my time; I wanted to find an issue in my everyday life that I could picture and wanted to solve as an idea for a problem-solving startup.
As a result, I noticed that contributing to people’s growth was the core of what I’ve wanted to do so far and various projects I’ve worked on. I was a cram school teacher when I was a student, and Spath School was a programming school. When I think about what I’ve spent a considerable amount of time so far, I was reviewing code for at least an hour a day and realized there were design errors but also many fundamental errors such as misaligned indents and missing closing brackets.
Something I can contribute to people’s growth through code review. I felt it was the answer. Then, I started thinking if I could start a business that supports reviewing code.
The original idea of SideCI during the US trip
At the time, I had this initial idea.
“Create something like rules or a dictionary that automatically gives suggestions such as ‘consider writing this way.’ The system can use those rules to review or mechanically edit or suggest editing before the human review.”
I presented this idea as CodeCat at an event for entrepreneurs, Incubate Camp.
But because I couldn’t purchase the domain name with CodeCat, I quickly changed the name to SideCI, which was available for purchase, and short and easy to remember. I wrote about the origin of the name “SideCI” in an in-house document as below.
Meaning of “Side” in SideCI
Side will be always by you, developers and support you. When you are about to make a mistake, it will quietly let you know. On the other hand, it learns a lot from you too. Side will not forget what you told it. When it gets a chance to utilize, it uses the knowledge to let you know.
CircleCI and WerckerCI might have been born to work instead of developers. Compared to them, SideCI was born to be right next to developers and help them as if it is a mentor, partner, or colleague.
In June 2018, SideCI changed its name to Sider. The above is the birth story of a code review automation tool, Sider in December 2013.
From January 2014, I spent most of my time having user hearings based on prototypes.
The next article of the series — how I grew Sider as a code review service after its launch — will be released next week on September 20th.
For more information about Sider, please go to our website.