Built With MongoDB: Workast

In 2016, Guillermo Gette was a technical lead at Expedia focusing on the front end development of its Australia and New Zealand websites. Like so many others, he was using Slack to communicate with team members. While Slack enabled rapid and collaborative communication, it didn’t do much to keep his team organized. So Guillermo kept a notepad close by to write to-do lists based on Slack messages, as well as a spreadsheet to manage developer tasks. But Guillermo soon realized that this practice made no sense. Why couldn’t he just put all these lists in Slack?

Guillermo first built a simple bot that put a to-do list inside a Slack conversation and then published the app in the Slack Marketplace. Encouraged by growing demand from users interested in his tool, Guillermo founded Workast, a full-featured project management system embedded in Slack that is used actively by more than 50,000 people at companies large and small. Workast has raised $1.85 million from investors Greycroft Partners, Spider Capital, Mucker Capital, and Dream Incubator.

In this #BuiltWithMongoDB story, Guillermo shares his vision for Workast and what he’s learned along the way.

Before you started Workast, you were just trying to solve the problem for yourself. Let's talk about how you got started.

In 2016, Slack was still an early-stage startup, and it was becoming quite popular in the tech community. I realized I could save a lot of time if I had a simple bot inside of Slack that captured to-do items from Slack conversations and created an environment inside of Slack to organize and communicate about projects. At the beginning, I was really putting my skills as a software developer to work to just build something for myself.

The initial idea was to quickly capture a part of a conversation and turn it into a to-do item. Then you could seamlessly move from Slack into Workast and manage lots of different to-do lists to get work done.

But once I saw how people used Workast, it became clear that for smaller organizations, the app became how the whole company ran. And for larger companies, Workast organized the work in (and eventually across) departments. People were drawn to the fact that they didn’t have to keep switching between communication and collaboration to project management. You didn’t have to invite people to join a project. They were there already because they were in Slack.

What were some of the challenges you faced early on?

When I put the app on the Slack marketplace, it took off right away and then two things happened. First, I got questions about new features. People wanted more ability to organize the tasks, tag them, and report on them in the Slack channel from which they originated. We started improving the product as fast as possible based on user feedback, and that led to more traction.

The second thing that happened was we realized we were in a red ocean market, which means lots of players. People have used many of the mature project management and to-do apps out there and have high expectations.

Our advantage in one sense was that we were embedded in Slack. In another sense, we were playing catch-up from the minute we went live. People loved the app, but then they’d also say, “Hey, I also need sub-tasks, assignments, projects, and deadlines.” They wanted templating, repeated tasks, tagging, advanced reporting, visualizations, commenting, and search, all the stuff they were used to. There is a lot of functionality that doesn’t sound exciting, and it doesn’t sound innovative, but people really wanted it in our product, and we had to build it quickly. Reducing the time from idea to implementation was crucial.

There's a moment in every entrepreneur's journey when they realize that their product can become an actual company. When did it feel like you had a real business on your hands?

At the beginning, it was mostly individuals and startups. Then, the Slack marketplace opened the door to a lot of other companies. Teams at Expedia, IBM, PayPal, and MongoDB started using Workast too. It was clear that we had hit a chord across a large market. The arrival of bigger companies was good news, of course, but also a challenge because we had to pass reviews by security, IT, and procurement, which means lots of work attending to certifications, documentation, and integrations.

We then had to figure out how to build a business and capture the value we were creating. Pretty quickly, people started asking when we were going to start charging. They saw the value and expected they would have to pay for it at some point, which was a good sign.

Our strategy was to focus on product-led growth. We decided not to focus on revenue but to allow people to use the product and eventually realize that upgrading made sense. So we don’t have a 30-day trial but rather we put counters on certain features: you can use them 10 times and then you are asked to upgrade.

Why did you decide to build Workast on MongoDB?

When you start a company, you don’t really know where your product — or your customers — are going to take you. You want the cost of change and evolution to be as low as possible. You want to move fast. That makes MongoDB, a schema-less database built for flexibility and experimentation, the right solution.

The cool thing is that as our company and our product have evolved, our database has evolved with us. We’ve never had to suffer downtime to update schemas or write migration scripts. Time to market was crucial for us, and MongoDB accelerates that.

MongoDB also scales and keeps on scaling. More than five million tasks have been created in Workast. Those tasks have to be actively there, they have to be searchable, and they have to be indexed. We don’t need to worry about it. We use MongoDB’s Performance Advisor every week, which tells us about performance problems and helps identify missing indexes, helping us make sure we’re scalable. Right now our cluster doesn’t need sharding, but when we do, it’s there for us. MongoDB is a database we can rely on — now and as we grow.

What features of MongoDB have proven to be most helpful?

Our architecture is based on Node.js and the AWS Lambda serverless platform. We use MongoDB’s in-database triggers to both automate actions in the database and also call out the Lambda functions.

Our database is growing and now we have users that have years of data in Workast. We realized that at some point, we will probably want to move older data out of production into an archive. Again, MongoDB has a plan for moving data to object storage in a data lake but still allowing it to be searchable. When we need it, we will use it.

We use MongoDB Atlas, so everything is hosted by MongoDB in the Cloud, run by MonogoDB, with lots of automation. Operations are really simple from our point of view. Our goal is to offload responsibility for everything that doesn't drive differentiating value. Uptime and scalability matter but we can push a lot of that responsibility to the Cloud.

We think about MongoDB as much as we want to. Not more. MongoDB acts as our database administrator, making sure the servers are updated so we can focus on building our software and business.