How & why we rebuilt our product from scratch in React

Meet Lior Brauer and Tal Haramati. Lior and Tal were the first developers to ever join our now 25-person (and growing) R&D team. They’ve been with us ever since we were just a few people in a room building a product that only had a handful of paying customers.

They also happen to be gems of human beings and good friends in real life. (In case you were concerned, that’s not how they typically dress…though Tal does pull off a headband rather well.) In this post, they’ll share a huge project they led earlier this year that transformed our product’s performance. We’ll turn to the microphone over to Lior!

It’s funny to think back and remember that when we first launched monday.com, there were no boards. Today it’s the core of our product, and we’re always super proud to hear how helpful they are to our users. We use them ourselves on a daily basis. One of the key advantages of boards is that they’re flexible and allow you to build your process any way you see fit. And just like we hoped, people started doing many different things with them. Crazy things. Ungodly things, in shapes and sizes we couldn’t foresee.

As customers began building boards that totally exceeded our expectations, the need for more powerful features emerged: sorting, filtering, batch actions, the timeline, new columns, and the new pulse page, just to name a few. This was great, but over time we started to notice two things: 1. It was becoming more complex and time-consuming than before to develop new features 2.

Our boards were not performing as well as they used to (not up to our standard of “boom performance”). We had built monday.com on a client-side technology called Backbone, which at the time was cutting-edge. For a while we tackled new challenges by micro-optimizing parts of that code, squeezing every bit of juice possible from the existing Backbone codebase.

This proved successful at first, but over time we noticed that our productivity was declining, the end results were not up to our standards, and we couldn’t ignore the nagging feeling that we could do better. It’s like that story about the lumberjack who was cutting trees at great speed every day. Over time his productivity declined, and he started missing his daily quotas.

Finally his boss asked him what was going on. “My axe has become dull and I am working twice as hard just to try and keep up,” the lumberjack said. “Then why don’t you take a break to sharpen your axe?” asked the boss. “Are you crazy?” the lumberjack replied. “I have too much work to do. I can’t take a break!” Deep down we knew that right thing to do would be to rebuild our boards from scratch with better technologies. We were already using and loving a newer technology – React, and have been writing all of our new features in it.

But the core part of the system, our boards, were still legacy Backbone. It felt painful any time we had to make any changes to our existing Backbone codebase, knowing just how much better our boards could be in React. Then inspiration came from the unlikeliest of sources: IKEA.

I had to go one night to return a closet that I had mistakenly purchased instead of a toddler bed—don’t ask—and Tal had come along to pick up a few things. On the way home, we got stuck in two hours of bumper-to-bumper traffic. With nothing but time to kill in the car, we started to daydream, and our fantasies turned to: What if we really rewrote all our boards in React?  We’re talking about re-building the core of our product completely from scratch.

As we sat in gridlock, we talked through all our reservations and concerns, and by the time we got home, we were both super psyched. I wrote the proof of concept (PoC) in 40 minutes as soon as I walked in the door, and when I woke up, I saw Tal had taken my initial code and fleshed it out into a working view-only board.

We showed it to the rest of the team and they quickly got as excited as us, and we were all eager to move forward at full-speed. But it wasn’t an easy business decision to make. We had to estimate how many resources such an endeavour would require. This is one of, if not the, biggest software development project we’ve ever taken upon ourselves. It meant that other important things we wanted to do would need to be postponed.

The new features we had planned would be delayed. For the next few months, half of our team would be working solely on this project, and at the end of it, we’d be exactly where we are right now product-wise—no new features and no design improvements. But as you can probably guess, we wouldn’t be writing this blog post if we had chickened out and decided to stay in our comfort zone. Our mission has always been to give our users the highest value we can from our product.

As software developers, a big part that means facilitating its evolution, and now was the time to do that. Our next challenge was to figure out how to keep our development values intact. One of our core principles when building a product is to break it down into a series of small product increments, each adding value on its own and allowing us to gauge that we’re on the right track. In this case it seemed to be impossible. It seemed we’d have to build a huge, time-consuming product without feedback along the way, without the frequent releases we rely upon, but only a sudden, huge and scary big release? F– that. We were not going to throw our principles down the toilet, no matter how big the challenge is. We came up with a solution.

We’re going to develop in production:

1. We didn’t change anything on the server, which allowed both old and new client code to live side-by-side without fear of either breaking.
2. We decided not to change anything about the way the boards work until we completed the new boards. This allowed us to move very fast, staying in already familiar territory, and not encounter any new unknowns.
3. Each new feature/step was released directly to production, even if most users didn’t use the new boards at the beginning.

So how did it go?

We did it! It was a ton of work but totally worth it. We gave our customers the ability to Beta-test the new boards along the way, and they gave invaluable feedback and helped us squash bugs along the way. We definitely could not have done it without them. We believe that rebuilding from scratch in React is the most significant and valuable investment we could make to our current and future customers. Our boards are now cheetah-like fast and we’ll be able to develop new features in a fraction of the time it used to take us!