Conveyor is the most ambitious product we’ve ever attempted. It’s one of those things that is either going to be brilliantly valuable or a brilliant failure. After nearly 2.5 years of active development, we decided to rebuild the entire client from native to Electron. While this meant that the product launch would take even longer, we decided it is worth it to deliver the right experience. A product like Conveyor is not minimally viable. It’s a workflow, and each step in this new workflow has to feel great for it to work as a whole.
Before I get into the details, let me share the story of how we got here. Since Conveyor is our next vision for Beanstalk we decided it could not just be a hosted web application. For us to make something great, the product had to live on developers machines as a client and provide the centralized hosting and collaboration. We needed to support the entire workflow and be as close to developers code as possible.
A product like Conveyor is not minimally viable. It’s a workflow, and each step in this new workflow has to feel great for it to work as a whole.
To do this, we had to make a decision between building a native macOS client or using something like Electron. A couple of years ago when we looked at Electron, it didn’t feel integrated enough in the operating system. The design and experience did not feel polished, and it felt like it would not provide the experience we wanted to deliver. We decided the initial client would be a native Mac app. While it’s limited in audience, it would allow us to create a polished experience from the start. As a company who works only on web applications, this was a big risk, and we felt it was worth it. So we went all in on native.
The process was an uphill battle to say the least. After two years and some really good hindsight, we realized it was not the best decision for our team. Not only did we have to learn an entirely new development process, but the process itself was changing in front of us with the introduction of Swift. As a team used to iterating quickly on design, the concept of handing off design felt unnatural and took much longer for us. Instead of us finding the proper process, we ended up fighting it.
Toward the end of last year we had a working client with a (very) small set of beta testers. It worked, and we even used it on real projects. As we got closer to our private beta launch date we had a chance to reflect honestly on the client, and we just weren’t proud of it. The web app is fantastic, but the client just wasn’t up to our standards. It was hard to update, and in reality, it hardly looked “native” anyway with the design direction we chose. We never really reached the performance and user experience goals that we picked native for in the first place.
We realized that if this was our future product we’d never be happy and it would never succeed. So we did what any respectable team would do: we threw it out. This was incredibly hard to admit, but I have no doubt it was the right decision.
Another look at Electron
We were only able to make this decision because we had time to look at the alternatives. It had been a couple of years since we researched Electron, and at this point (Dec 2017), it had matured a lot. We decided to do a small proof of concept. Surprisingly it was a breath of fresh air. Not only because the tool set had improved, but because we missed the agility of working on a web application. The development experience was familiar again, and it felt fantastic. After fighting the native client for so long, and dealing with some emotional ups and downs, our motivation and enthusiasm was in full force.
Now here we are, a few months later, and even though we are completely rewriting the client it’s moving extremely fast. From the design, to the syncing process, to the tools we are using it’s turning into a product we are extremely excited and proud to build. The solution we are putting together is based on all of the mistakes we made the first time around. And it helps to have 2.5 years of iterating on design along with a very good backend to support it.
It’s worth the wait
This was a really hard choice and it set us back about six months. It was the correct decision though. With a profitable company that affords us to be patient and a mission to only work on things that we get excited about, we had to do it. When it’s done we will have a much better experience, and even better, it will work on multiple platforms!