After much internal discussion, we’ve decided to stop working on Conveyor.
Before I get into the details, I want to thank all of the companies who invested their time in Conveyor. You helped us test and put up with our endless questions, surveys, and calls through the process.
I also want to thank the team. Wildbit exists for the team, and Ilya, Eugene, Dima, Chris B, Jeremy, Brian, Derek, and many others poured their heart and soul into this product. At times it was incredibly exciting, and at others, it was completely draining. Natalie and I are so lucky to have a group of passionate, thoughtful friends to work beside, especially on projects like Conveyor.
A decision like this comes with plenty of emotions, questions, and reflection. To pull off the vision for Conveyor, it requires a shift in how developers and software companies think about version control and task management. It requires time, education, and the finesse to experiment with different audiences. After five years of effort and not enough traction, we reached a point where we had to make a decision. It became clear that Wildbit can no longer continue to work on Conveyor, and as a team, we all agreed it was the right decision.
Making tough decisions
December marked a significant investment—roughly 4.5 years and $3 million—since we came up with the idea of Conveyor. Our vision was to blend the Git branch process with task management, removing the redundancy in status updates and bring it closer to where developers work: the Git client.
It was an extremely ambitious project. Looking back, it’s incredible what such a small team pulled off. What started as a web app turned into a native Mac client, which was then torn down and rebuilt into an extremely performant electron app. It’s an entirely new tech stack and environment compared to what we’ve worked on in the past.
As it stands today, we’ve been able to blend project management beautifully with Git, reducing redundancies, and keeping task management closer to the editor. It’s opinionated on purpose. In the second half of 2019, the team was on fire launching things like the Agenda, Team page, Sub-tasks, GitHub integration, and a lot more. The product works extremely well, and we’re proud of it.
But even with solid validation on the problem and a fast, reliable product, adoption was slow. We’ve invited many groups of people, from individual contributors, to project leads, to agencies, but it didn’t resonate the way we had hoped. We still didn’t get the product/market fit we needed.
Hindsight is always 20/20, and looking back, there are plenty of things we would have done differently. Our initial thought was that we had to own the entire development process, from the Git client to Git hosting to task management to code review, and abstract the unnecessary steps from the development process.
While I don’t think we were wrong, we should have validated those steps individually as best as we could, iterating along the way. Instead, we kept convincing ourselves we needed that “next feature” for it to make sense. One example of this is the Git client. We could have tested the client to work with GitHub as a proof of concept, and with positive feedback, keep building on top of it.
The biggest lesson was waiting too long to make this decision. Five years is an incredibly long time. The progress was motivating, and we had glimpses of validation, but nothing near what we’d seen with previous products. We kept convincing ourselves we were just about to turn a corner, whether it was the Electron rewrite, trying a new audience, or that next crucial feature.
Looking back, I’m amazed that we fell into these traps. We’ve been writing software for twenty years and have enough successful projects to give us confidence. And that fact is the root of the issue. With a talented team, a mature and profitable business, and confidence to solve any problem, we looked at this product differently. We had time to experiment without a negative financial impact, and the team behind Beanstalk was tackling Conveyor. We convinced ourselves that minimally viable was no longer the proper approach for a team like Wildbit.
It’s fair to say that we stand corrected.
Seeing the positive
In honest reflection, working without validation for such a long period led to feelings of frustration and a decrease in morale. We’re human, and as Dan Pink says, we all have the “…need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.”
We believe businesses should be human. Understanding how our motivations impact our happiness at work, along with the ability to act on that understanding is something we care deeply about at Wildbit.
We’re fortunate that shutting down Conveyor has no direct financial impact on Wildbit. By diversifying across multiple products, we are able to experiment. And after stopping work on Conveyor, we’ve opened up new opportunities for the team.
Chris B and Eugene jumped into People-First Jobs, which we recently launched. It also provided the space to apply these lessons to a new product, DMARC Digests, which Ilya collaborated on with Matt. Dima and Jeremy were able to transition to Postmark, allowing us to make progress on some projects we’ve been hoping to tackle for a while.
What’s next for Conveyor?
We’ve invested significantly in a solid product that works well, but it still requires effort to get the market, messaging, and product in the right place. We’ve considered selling the product, giving it away to a coding school, or open-sourcing it. The correct option hasn’t yet presented itself, but we’re considering all ideas.
Considering that many people still fully believe that developer tools are fragmented, waste time in over-communication, and are too detached, we’d love to see it turn into something.
Our goal is to find Conveyor a new home by the end of September. We hope someone finds value in the overall concept, and it inspires something new. There are still several companies using the product, and we miss Conveyor ourselves! Whether that it is with the Conveyor code base or something from scratch doesn’t matter. We hope someone, or some organization, might find value in the concept and application to take it on, enabling everyone to use a product like this in the future.