Hi Gabriel! What's your background, and what are you currently working on?

I’m Gabriel Benmergui, 34, and currently, a Senior Product Engineer at CircleMedical, a YC backed startup in the Medical space. Recently, I’ve designed, managed and implemented an end-to-end EMR - the software used by doctors to document and treat patients.

Before becoming a Software Engineer, I was an aspiring professional Go Player and became the #1 player of my generation in all South America.

The Game of Go was my passion in my teens and 20’s. I wanted to make a living with the game and making it professionally was extremely competitive: thousands of players would play tournaments every year and less than 15 people world-wide would achieve the title of professional.

So I decided to build a Go Server that rivaled the current king, that was implemented with borderline expired technology. I founded Kaya.gs along with a partner: from nothing to a playable server in about 2 months back in 2011.

One of the biggest challenges was the business model. Playing on a server is free, so most servers live by the Freemium model. Some features and services would be unlocked with a membership.

Because we would take a long time to build a competitive freemium model and to bootstrap with that strategy, we chose to crowdfund the project. There was a huge need for a new space, that would develop new features faster and be more modern than the current options: the crowdfunding campaign let us get funding in the order of 20.000U$S. 

‍

What motivated you to start Kaya.gs?

In 2011 I went to Korea to study Go while secluded in the mountains. That was my last chance to become the first Go professional player in South America. At one point the opportunity was offered to me, a dream I had had for a decade. But I thought that I would be so far off-the-top of the game that it wouldn’t be my best contribution to the game and the community. I wanted to use my software skills to build something for everyone, not only for myself to compete.

At one point I was building an online Go school and had dozens of recurring paying users, but I ran into a huge roadblock: It was very hard to extend services officially to the biggest Go server in the West. This happened because the live servers of the time had been built a decade before and had a very limited vision of what could be done: they didn’t see themselves as a platform for the expansion of Go activities as much as a technical feat of being able to play the game online.

Kaya.gs was a very unique project for many reasons, but what got people really excited was the vision: the idea that something new and exciting would happen and that the community would be able to thrive with new community-oriented features. We had huge participation from the users in what had to be built, and even extended an Open Source part of the project for other developers to build AI’s, time systems and tournament systems.

Back then I had had only about 1 year of web software engineering experience which will be an important piece of information later on. I had worked with startups and loved the ethos of building something for people that wanted it.

‍

How did you build it?

The first step was building an architecture for it and a demo for ourselves: could we feasible build the first responsive HTML real-time GO server?

The tools were very new at the time: socket.io for Websockets, node.js for event emitting/channel management, Ruby for the server (with a microframework called Cuba). The front-end was made with jQuery, but a funny thing for the Front-end Geeks is that we build a React-like rendering engine to only update the correct components instead of re-drawing the entire page.

With my partner we sat down together, we picked the tools and the design, and we started coding as fast as possible. One of the most magical moments in the process was the first time that we could place a stone in the board and it worked real-time: like hearing your baby speak!

Technically there were many obstacles: WebSockets was not reliable enough for many browsers and browser setups: the javascript community did not offer nearly as many tools and projects as it did later on so you had to build a lot from scratch. And games are *hard*. And real-time games with time-sensitivity are even harder.

We wanted to crowdfund the project in Idea.me, a Kickstarter-like company that was made in Argentina (because Kickstarter was not available for Argentina, and I think still isn’t). The day we launched the campaign since most of our users were outside the country, their donations were blocked by credit card companies and the sort. Nobody could pay. So we shut the project down from the idea.me website, and built one on our own website overnight, with Paypal.

One of the fondest memories was naming the funding section on the website “Candy” with pink colored cues and icons. People found it hilarious that their curiosity led them to find that “Candy” was actually us asking them for money.

We priced much like a Kickstarter campaign, different Tiers meant different perks and benefits, but mostly subjective. It was borderline a donation, because what people wanted was to see a new player in space more than anything else.

Which were your marketing strategies to grow your business?

I think Crowdfunding campaigns are fantastic for games. The people that donate become evangelists of the project, love being involved and share actively with people. We also had a very active feedback channel in a public forum, where we were the only official Server that responded to user inquiries. That gave us a huge influx of users and feedback. We had over 300 special account users, some of which individually contributed over 100U$S each. This was significant for the space because we didn’t yet offer a superior product, but the promise of one. (A funny story is that a user donated 100U$S with bitcoin at the time, which was around 3 dollars each. We sold the bitcoins when it hit 60U$S, thinking we hit the jackpot!)

The most difficult part of growing a new Go server is the chicken-egg problem: it’s a market place between players of different strengths, and if you don’t have enough players you don’t get enough players. We attacked this problem in many ways: we organized prized tournaments, we added passive activities that engaged users for longer periods and would mean more presence. One of our most effective tools was to add bots that made it so a large number of players could play even if they found no (human) opponents. We used to have about 100 people online constantly, and we had 10’s of thousands of registered users. The number of games played was well over 10.000. 

‍

Which were the causes of Kaya.gs’s failure?

The whole Kaya.gs project was quite the rollercoaster. From the frantic fixing of our crowdfunding campaign to the server’s first release which was Christmas! I still remember my family trying to get me to do a toast while I was talking with the first live users of the website. We had a blast going all against the current of standard product-releases. We released every Friday night and people would flock to the server just to see the new features. We gradually increased participation and the number of games. But our growth stalled, then our income, our motivation and our capacity to develop new features. 

Kaya.gs failed for many reasons at the same time: it’s easy to see sometimes how any one thing that had been flipped could have given Kaya.gs a longer lifespan to fix other issues. I would categorize 3 big failures that fed on each other. The first was the product, and solely my responsibility. I was selling vision with Kaya.gs and that vision consumed resources and mind-share to build creative and innovative features but neglected the bread-butter. We had reliability issues with frequent server crashes, and that would make the playing experience unreliable. We should have made the core-features of the service iron-proof before building the innovative features. We cranked out 2 features a week in a space that was used to getting 1 feature every 3 years: that was part of our identity, but we were already so much ahead in those terms that we should have tended to the core experience.

The second was engineering: we made huge technical blunders in terms of design and planning. This was due to our inexperience mostly and was in many ways unavoidable. It was a novel architecture, in a time where everyone was moving off to build mobile games. We built Kaya.gs with experimental features that were turned off by the browsers often, had no DevOps (I manually restarted crashed servers), and this eventually affected our capacity to develop itself.

The third one was morale. After a year working on it, we were running out of ramen-money and we were not seeing progress. Our progress deteriorated, and we were ineffective in addressing that. We started to have friction between the founders and that lowered productivity to a halt. When things aren’t going well, it turns a mechanism in your brain that wants it to fail fast, as if it is about survival in the long term. I have a lot of regrets about how I handled that with my co-founder, but in the end, I think it wasn’t about mismanagement, but that we were not making the progress we thought we would with the business.

Once our technical productivity was severely diminished, we ran out of funds and didn’t understand why our product was not attracting swarms of players, it was time to move on. I would have loved to keep the project alive as a side-gig, but it required significant technical effort to keep it alive, so when I got a job that could pay rent, I closed the server down and open-sourced the code. I frequently talked with the most hardcore users of the server, some of which donated a lot of money and effort. They understood I did the best I could, I was there every day, working every day, and they could see I was not having enough traction to make a living. I did not get angry emails, so I think people moved on!

Which were your biggest mistakes and challenges you had to overcome?

So many mistakes! I remember understanding for the first time what it means to become a sort of public figure. In a semi-private space of Kaya.gs (a private channel, but accessible for many people) I made a jokingly sarcastic comment about a user making an unreasonable request. It was the writing style of that space, which was not taboo or insulting. A user took a screenshot and made a huge fuss in another forum where that would be taboo: a classic case of Schadenfreude. The first time I had to learn about PR meant, about watching what you say and how you say it because it can be taken out of context.

This is related to another challenge we had: we wanted to be the Server where we would do everything for the user. Go Servers had a famous reputation of being trigger happy with banning and treating users with some contempt. Some servers would ban you for just mentioning other servers! We, on the other hand, created a place for users to vote on features and participate in product prioritization. This gave us invaluable feedback, but it was also unruly. Consumers are all-demanding and it’s particularly insidious with free/freemium products: when you give the user some power and they cannot exert it, they become detractors. A lesson that is very evident in services like Twitter or Reddit, where it's filled with people that post constantly every day, pay nothing and still deride the services they use.

There were plenty of Engineering mistakes, but I think they stemmed from inexperience and from product direction. I wanted to build everything, so we had everything half-built. I would tell myself to focus on key features first, end-to-end, before moving on to the next one. Another thing I learned later in my career was being more data-driven. I should have picked the key metric (# of games) and made sure that was the metric that improved every single day. That would have done wonders for the three issues: would have focused Product, would have made Engineering easier by having fewer features and work better and would have raised Morale had we been successful at improving it.‍

‍

Which were your expenses? Did you achieve some revenue? In the end, how much money did you lose?

Our key expenses were our own living expenses. We lived on a ramen-budget after technical expenses. Infrastructure and Engineering costs were low. I think this is one part we did right, very low expenses gave us a year of runway with 20.000U$S.

What we lost the most, of course, is on opportunity cost. Our monthly revenue was about 2,000U$S but the model had ups and downs. We knew that if we grew our user base we would have to add another kind of subscription service to fund ourselves long-term, but we did fantastically for what the space could do back then.

‍

If you had to start over, what would you do differently?

Gabriel, you need to sort out your execution risk. You don’t have the technical expertise to run all of this so make sure you get the right people to help in time to avoid pitfalls or build a team around it. And focus: make sure that what you are building is the right thing to build, every single day. Build for impact, even if it’s boring. Forget about the bells and whistles!

‍

Which are your favorite entrepreneurial resources?

I am a YC fanatic. I enjoy Paul Graham’s essays and Hacker News for startup/entrepreneurial information. But what I would recommend someone the most in any business is making sure you know the domain. Understanding what you are building and for whom is the most important Product detail of everything. That’s why most successful companies are built by people that make a product for themselves or for industry they work in.

‍

Where can we go to learn more?

This might be a good opportunity for me to open up my portfolio page into a blog since I wanted to do that before. My port-folio page is conanbatt.com.