My co-founders Royston Tay, Kwok Yang Bin, and I met when we were all in Palo Alto as part of the National University of Singapore Overseas Colleges (NOC) program. Roy and I were roommates and became friends. We had no idea that we’d start a company together, or end up as the best man at each other’s weddings. Back then we were just three guys in school, building an application.

It took a long time before our app became a business. After school, we first offered Zopim for free. We were surprised when people started using it, and then again at the point people started paying us! And once we were a company, we had no idea that the business would become so successful. We were just focused on trying to get a proof of concept that worked, and we did that.

At the time, we weren’t thinking about things like scale. It’s not the first thing you think about, and so the first version of our product was impossible to scale. It was a bit like, “Look at this huge monster we’ve created.”

We also didn’t have the luxury of money in those early days. We never managed to raise rounds of funding, so we never could afford to throw money at a problem. It was about a year into building Zopim that we realized we needed to figure scaling into our architecture and we forced ourselves to think through the problem without using expensive hardware. This eventually paid off because, at the point when Zopim was acquired by Zendesk, the way we powered Zopim was actually very good. Our hosting costs were very low in relation to the amount of traffic. But it’s one of those things that was forced by necessity, rather than something we consciously decided along the way. We had to design in a way that didn’t require us to buy a lot of servers.

I’d never say that everyone should do everything with scale in mind because you’ll never get a new product off the ground, but even today, as we evolve, we try to factor in scaling. Half a year into building your product is probably a good time to start thinking about how it’s going to scale, and then to really build that mindset into the core of your engineering. Everything you do, ask: Will this be able to scale to 10x the size? If you always have this mentality, you’ll prevent a lot of heartache in the long run. You don’t want to be in the situation where your user base is booming and you can’t deal with it because your architecture is not designed to support it.

If you look at our code from the beginning to where it is today, it’s gone through an evolution of experience and knowledge. And so I guess if there’s one thing we’ve learned, it’s that you shouldn’t be afraid to go back in time and look at what you did before. If it warrants a rewrite or refactoring because you just weren’t as good before as you are now, you should go ahead and make the changes. It’s only going to become more painful to go back and rip apart later when you’re farther along.

Refining is always a continual process, but to pinpoint an example from our early days, the first version of our product was based on Flex, which creates effects for Macromedia Flash. It seemed like a really good idea at the time—it was promised as cross-platform and able to run on every mobile device, but it was apparent two years later that was not going to happen and that choosing Flex had been a terrible decision. So we had to make a decision, when we had this entire codebase built in Flex, to rebuild the product, and we did. We got to the point where everyone internally knew our codebase built in Flex was a bad decision, but it was that fear of ripping off the bandaid that was holding us back. We weren’t sure that it was going to be worth starting over. We were still asking if we could plow forward and come out fine on the other side. It was also a decision that involved more than engineering because we had to let customers know that we were going to deprecate the old codebase. It wasn’t an easy decision, but once we did it and got 2-3 years out, it was clear that starting over was a great decision. It just took us too long to arrive there—we should have recognized Flex’s pitfalls sooner and just ripped it apart to build something new. And even though it took us longer than it should have, doing it really paid off.

Haven’t read Startupland yet? You’re in luck. Through June 30, you can order directly from the publisher and receive 30% off using the discount code: VBK10

Wenxiang Wu is Director of Engineering for Zendesk’s Zopim Live Chat product. Before that he was CTO and co-founder of Zopim, as well as the self-proclaimed VP of Partying (though he gracefully stepped down after becoming a dad). Follow him on Twitter @VP_Partying

This series features first-person narratives about the journey into ‘startupland’ from founders and startup executives currently using Zendesk, Zopim, or Inbox. Interested in posting? Email us at


This post originally appeared on the Startupland blog. 

The following two tabs change content below.
Co-founder / VP Engineering