Andrei Soroker on startups getting everything wrong—and Slack eating his lunch

Andrei and his co-founder Peter.

A short while after we launched Chapp, I received an email from Andrei Soroker. I didn’t know much about him, but he seemed friendly enough. He asked about meeting up, as he planned to visit in Vancouver for a couple of days. So, Eric Shelkie and I connected with Andrei and his business partner, Peter, and shot-the-shit over beer, sake, and sushi.

Since then, I’ve had the pleasure of working with Andrei and his colleagues. I watched as they shuttered Kato and launched Sameroom in what seemed like the blink of an eye. Andrei’s also helped me by answering some startup questions and introducing me to the notion of distributed teams.

In my work at smashLAB a few clients have become friends. I feel that way about Andrei, and I’m very happy that he agreed to help others on Officehours, as an advisor. Today, he answers some of my questions about how tough startup life can be.

After two years, and a couple of millions of dollars of investment, you shut-down your startup. How does that feel?

I wouldn’t say we shut down the startup—we built a new product and killed the old one. Same core team, same investors, same cap table.

It feels OK—I understand it’s a part of the game. I’m impressed how much we were able to get done with $1.9M.

It took us a long time to announce that we’re killing Kato after we pivoted, so I had a chance to detach emotionally. To be perfectly honest, we’re not even done killing it yet, Kato is still up and running—but you can no longer sign up.

What was your low point during this process?

Getting started, and transitioning from going to work to launching a company, was the scariest point. It was also very exciting, so I wouldn’t call it a low.

In retrospect, 2014 was one big low point. We were having the shit kicked out of us, while trying to maintain a straight face.

Sounds pretty painful. Why not just pack it up and get a day job?

After two and a half years, we’re more determined to succeed than the day we got started on this journey. This is the best part, and it would never happen to us at a day job.

We started the company because we got tired of putting everything we had into products that ended up not working out, and we didn’t know why.

We’re OK with failing, as long as we get to blame ourselves and learn.

Business partners Andrei and Peter taking a brief time-out.Business partners Andrei and Peter taking a brief time-out.

What went wrong with Kato?

Kato faced a monster unicorn (Slack) not too far into the journey. That’s really the main thing that went wrong. We also made a number of product and people mistakes, but none of those were fatal.

We entered the team chat market at a perfect time for a small startup—the incumbents were practically begging to be disrupted. Early 2013 was a time when a crappy MVP could seriously move the needle.

We launched Kato after six weeks of development and about $200 of investment, $99 of which was for an Apple developer license. We did everything by the book: launched quickly, found early customers, iterated like crazy based on feedback.

A couple of months in we had $80 MRR (eighty, as in eight zero), which basically meant we were profitable, since we had no salaries and the service was hosted on a cheap Linux box at Peter’s Palo Alto apartment, with Business Comcast (~$50/month) being the only expense (which Peter needed anyway, for home internet).

From what I hear, Stewart Butterfield was a Kato user before Slack launched. Is this true?

The Slack team checked out every competing product. They played around with LeChat (Kato was called LeChat back then) for a couple of weeks.

I had a pretty great conversation with Stewart. I didn’t know who he was then. In hindsight, they had the awesome advantage of stealth mode. We had to launch as soon as we had something, to raise money. You’ll notice that Stewart calls me Bob—I appeared in customer support chat as “Bob” in those days. That was as stealth as we could get.

It would’ve been great to have a friendly rivalry with them, but that was not to be—they just wiped the floor with everyone out of the gate.

Before Slack hit the market, Stewart kinda liked Kato. Before Slack hit the market, Stewart kinda liked Kato.

If you could go back, what would you do differently?

Initially, we tried pretty hard to build an engineering team based in Silicon Valley. This didn’t work well with our DNA—we were all about efficiency and very fast execution. We later learned how to hire remote developers and put together an amazing team. If I had a do-over, I would go the distributed route right away.

You’ve had a lot of requests to keep Kato alive—and perhaps open source it. You’re doing neither. Why?

Competition in the team chat market is in trench warfare mode right now—it requires lots of money and time. A startup at our stage is not well-equipped to compete in this environment.

The reason we don’t want to open source Kato is because we don’t want it to become this.

This is IRC.

We’re glad that so many people understood Kato for what it was and saw its benefits. That means our core ideas hold water. Maybe another company will want to continue working on Kato—it’s definitely an option. If no one develops an equivalent, maybe we’ll try again in a couple of years. The Kato model has some important departures from the established approach, which makes the system scale across large companies. A product with this property will have to exist in the future.

You’ve started a new service called Sameroom. Tell us a little about that.

One of the reasons we decided to stop working on Kato was because we realized that it’s impossible for everyone to use the same chat system. We realized that every company bigger than a certain N will always have multiple chat services used at the same time. This means people will have to resort to email to communicate, which is exactly what we’re trying to cure. So we turned our attention to interoperability between heterogeneous chat systems.

Sameroom began as a set of low-level functions that allowed someone to set up real-time connections between conversations in different systems or teams.

Now we’re using this low-level functionality to provide more meaningful features: for example, the ability to reply to public mentions and DMs on Twitter from Slack.

What made you choose to work on Sameroom, instead of fighting Slack more directly?

For every million we raised, Slack raised 180. This is what fighting Slack directly looks like.

I’ve worked with you on Sameroom, and am convinced that once people figure out how magical it is, they’ll be blown away. Why hasn’t the world gone crazy for your product, yet?

Sameroom, in its current bare-bones state, has product/market fit. If it didn’t, we wouldn’t have 50 paying customers just a few months after launch, with no press or publicity of any kind.

It appears the market is simply too narrow at the moment. Not enough people feel that the problem of dealing with multiple chat systems is bad enough to go looking for a solution, and then pay for it.

I think intellectually Sameroom is a bit of a head-scratcher, too. Many folks expect another chat client that is able to work across different systems. When we tell them to just use their Slack and bridge certain channels or groups with outside systems (including other Slack teams), not everyone can visualize that right away.

And that’s just the basic use case of connecting two things together. It can get a lot more complicated:

Here we have 11 different teams, where each team has a chatroom that is shared with the other 10. This is extremely powerful, but too meta for the world that’s only starting to grasp the concept of modern group IM systems.

What kinds of integrations do you have planned for Sameroom, in the coming months?

We hope to release an integration with WhatsApp, which will complete our consumer footprint for the time being.

We’re now working on more advanced features that would make Sameroom useful for entire companies, not just individuals. For example, you’ll be able to respond to customer questions coming from Facebook, Twitter, Skype, or Intercom from your team chat. This would really let you bring all your communication together in one place.

You immigrated to the United States at a young age. How’s does this change your experience as a startup founder?

Not that young—I was 13 and a half.

This is a complex question—it’s hard for me to imagine what I would’ve been like if I had been born in the US or if we had never left Russia. Learning English, figuring out how America works—that was definitely my first startup (buying a house at the previous peak and dealing with that was the second).

Startup founders have a certain relationship with risk that isn’t quite normal for most people. My tolerance for risk clearly stems from the experience of seeing my parents—at the age of about 40—sell everything and move to a foreign country, with two young children. The risks I’m taking are nothing compared to that.

It probably goes without saying, but being fluent in Russian gives me an enormous advantage in hiring engineers. We would’ve never been able to do what we had done, without being able to hire directly in Russia and Ukraine (we would’ve run out of money a long time ago).

Your team is distributed. How does this work?

Well, we’re definitely not playing house (reference). It’s a lot of long days of lonely work. We all have families, kids, so we’re not going to work to socialize and play ping pong. We haven’t met some of our employees in person. We finally met our first engineer after having worked with him for nearly three years.

When you’re remote, it’s impossible to hide—you can’t just pretend to be working by sitting at a desk: nobody can see you, nobody cares where, when, or for how long you sit.

The only metric for success in a distributed team is work itself: does it happen? (code contributed, blog posts written, signup increases, etc). Being able to get work done is the only “culture fit” we’re looking for.

It absolutely sucks to handle crises in a remote environment, which a huge motivation for building products that just work. We strive for calm, measured operations.

Finally, we do everything possible to keep our burn rate as low as possible. Hiring remote helps on three fronts: no need to have an expensive office; you don't have to pay SF salaries to folks who live in Moscow; and there is virtually no mercenary churn—a remote position in itself is the best perk you can get.

OK, one last thing: a team spread across the globe is way better at customer support, because SaaS customers are everywhere.

Andrei on a day off (a rare occurance), hanging out with his kids.Andrei on a day off (a rare occurance), hanging out with his kids.

Is there one thing you think startup founders always get wrong?

Oh, I don’t know, this is a hard one. Obviously, the overwhelming majority of founders are ultimately wrong about everything, because most startups fail.

There doesn’t appear to be the concept of “always” in startups, with one exception—things always go wrong.

Maybe a common thing to get wrong is to believe that it’ll be easy, in the very beginning. It’s never easy, although the spectrum is quite wide. Hard-while-VC-funded is much easier than hard-while-unfunded.

You’re offering sessions on Officehours. Who would you most like to help?

We went through the Techstars program in Boulder, so a lot of my thinking about helping others has been formalized by the Techstars approach, which even has a name: give first.

This means, if you can help—help, but don’t expect anything in return. It’ll come back to you, because that’s the way the system works. And the reason the system works is because people help each other out without expecting anything in return.

This means I’m not very picky—I’ll help anyone who thinks my input might be helpful.

So, here’s your chance to get startup answers from someone who’s in the trenches. Curious about funding, building a distributed team, or when it’s time to pivot? Request a session with Andrei and get a helping hand.