Built With MongoDB: Memora Health
Built With MongoDB: Go
“Social media was supposed to augment our friendships and give us more to talk about — but it’s actually starting to replace our relationships,” laments Sean Conrad , the co-founder and CEO of Go. After 10 years of working at large tech companies and bootstrapping a multimillion-dollar gaming company, Sean started building Go , a social app focused on helping friends create plans to hang out in person. Combining data science, social networking, and event aggregation, Go provides users with a custom, curated feed of cool things to do and friends to do them with. Go is live in New Zealand and (very recently) Australia with over 40,000 downloads and 500 businesses. The startup has raised $6.7 million in seed funding and has been building with MongoDB from the start. For this edition of #BuiltWithMongoDB, we spoke with Sean about the business, being a second-time founder and CEO, and his experience with MongoDB. MongoDB: You actually started building during the COVID-19 pandemic. How did that impact the product, given that your mission is to bring people together in real life? Sean: It impacted us in so many ways. We researched the space throughout 2019, and started building the app in early 2020, planning for a fall release in Portland or Los Angeles. And then the pandemic hit the United States. We realized it was jokingly bad that we were building an app to bring people together just when social distancing was becoming a requirement. For a month, we contemplated a lot of possible ideas, and we had some cool ones, but our passion was really about making offline connections stronger. We spent the summer working on the product, and then launched in New Zealand because that country had handled the pandemic well and reopened. The product has been a huge success in New Zealand, and after iterating on it, we recently launched in Australia. Our plan is to launch in the United States, starting from Los Angeles, during the summer of 2021. MongoDB: You mentioned that you've used MongoDB before. What has your experience been like with MongoDB as a 2x founder? Sean: At my previous company, we scaled up to about 30 million downloads, and we ran it on MongoDB. We were not database experts, and it was very easy to use. It was 2013 when we started using MongoDB. We had our hiccups and had to learn what indexes were, but we became really comfortable with the platform. For Go, we picked MongoDB out of comfort. When we got started with Go, MongoDB Realm was still in beta. We would’ve used it had it been around, but we built our first product on Firebase Firestore. Firestore ended up being a bit limiting for us because we wanted to build a feed-based system (in Go, it’s showcasing a series of events or things to do that are interesting to you and your friends), so a lot of filters are necessary. That requires many different types of unstructured data that’s difficult to put into a simple schema. Managing these things demands a lot of documents and data duplication, and MongoDB was a good fit for that. We like that Atlas has full-text search built on Apache Lucene , which is a powerful text search library. We are just getting into that. In addition, most of our compute runs on AWS. We use a lot of containerized stuff on AWS, and a little bit of Lambda stuff, and we’re moving to a serverless environment. I’m not sure what the future of Go is, but I’m confident MongoDB will play a part in it. Our mobile app is written in Flutter, Google’s competitor to React Native. We like that quite a bit. MongoDB: What is the last technical podcast you enjoyed? Sean: It’s All About Widgets , a podcast about Flutter. We’ve got a really talented group of developers on our team — two of them are ranked in the top 15 Stack Overflow Flutter contributors! One of our developers Raouf Rahiche spoke on their second episode . It was really cool to hear a team member talking on this podcast. MongoDB: As a second-time founder, what is one thing that was unexpected for you in building this business? Sean: This is the first business in which I’ve raised funding, and I couldn’t have done it without my co-founder, Jesse Berns . For my last business, I started with something small with a few people, found product-market fit, and grew that. With Go, we started with a much more grand vision in mind, so it made sense to operate more like a traditional Silicon Valley startup, raising capital and growing the team quickly. With all startups, you’re operating with very few known facts, but when you raise money everything just tends to get bigger, faster, and I always say this is like ‘operating on hard mode’ — but in our case, it’s worth it. Our goal with Go is to help people manage their friendships in the same way that LinkedIn helps people manage their professional lives, and if we’re successful, that’ll entirely change how people make plans and optimize their friendships for more time together face-to-face. It’s built to inspire us to live our ideal lives, whether that’s basement art shows, unforgettable live music, lunch with friends at a special place that could only exist in your neighborhood, or a slow bike ride down by the river. It’s built for the mundane and the thrilling and everything in between. We’re at a really exciting moment in history where all the trends — adoption of mobile, the upcoming end to the pandemic — are going to enable a culture where people want to find humanity and joy in person, and human-facing tech is going to have a big impact in the next few years. With Go, we’re really excited to be part of that. Looking to build something cool? Get started with the MongoDB for Startups program.
Built With MongoDB: Buffer
I first became a fan of Buffer during graduate school. While managing social marketing for student clubs and conferences, I relied on Buffer to manage our fun marketing campaigns. Buffer is a popular social media software that enables small businesses and content creators to plan, publish, and analyze marketing campaigns across social channels. It serves 67,536 customers across over 85 countries. The company has over $21M annual recurring revenue and has been in business for 10 years now. I recently had the opportunity to speak with Dan Farrelly , Buffer’s CTO, about the fast-growing company, his experience with MongoDB for Startups , and the challenges of growing into a CTO position. MongoDB: Let’s go back to February 2014. At that time, Buffer was a much smaller company — only about 15 people, compared with the more than 80 people now. What drew you to join? Dan: Hands down, the culture. There were two things that were unique about Buffer at that time: First, it was an entirely remote team. This was rare in the pre-pandemic world. Second, there was incredible transparency both inside and outside the org. The company was so open about salary that on the Buffer Jobs page, it had an estimated salary calculator based on role and experience. Internally, all revenue numbers and company metrics were accessible to the entire team. The executives being an open book enabled trust and free communication across the organization. And like any startup, we were all-in. Early on, I remember being at a taco shop on a Friday evening when the then-CTO texted me that the servers were crashing. I opened up my laptop at the restaurant and just started troubleshooting — doing whatever I could to try to mitigate the issue. Many people depended on us to manage their social identities, and so with a taco in one hand, and a phone on the other, we figured it out. Working at a startup is such an incredible learning curve; you have to be scrappy, push the boundaries, and find creative ways to deliver results. MongoDB: Why did the team decide to build with MongoDB? Dan: Our culture has always been engineering-centric, focused on shipping code as soon as it’s ready for production. We encourage continuous delivery of our applications. MongoDB’s products resonate with that lean culture. MongoDB doesn’t require schema migrations; the flexibility and ease of use enabled us to practice the type of engineering we wanted. MongoDB became our partner in being fast and delivering often. An additional benefit was the ability to scale easily: one type of application we were building (content scheduling for social media) had massive collection of data that had to be scheduled which required very high throughput — we were posting hundreds of thousands of times a day for social media accounts. MongoDB Atlas allowed us to scale and ensure we didn’t have to worry about our database over the years. MongoDB: Had you used MongoDB before joining Buffer? Dan: I had taken a MongoDB University course in 2012 focused on MongoDB for Node.js developers, and I had built a few side projects and prototypes with MongoDB. The course itself was fantastic: it not only talked about basic things such as setting up replication, sharding, and how the database itself works, but it also talked about some of the more complex elements (how drivers work, write concern, and fully leveraging the database). But the best way to learn about MongoDB was putting out fires at Buffer. Early on, we had monitoring and scaling issues, not with the database but with the code, and our team had to get smart about diagnosing specific issues in our application. MongoDB: What advice do you have for an engineer who wants to grow into a CTO position someday? Dan: Engineers can pursue their own roles and do a really good job while still having a limited perspective of the company. In order to become a CTO, you really need to broaden that perspective, and understand how technical strategy supports business goals. The CTO doesn’t have to be the most technical person on the team, but has to have a well-rounded view of the business and also effectively communicate across the stack. Transparency at Buffer helped me develop a wider perspective of the business. If you have ambitions to grow into a CTO role, build relationships across the organization — on the technical and business sides — and think strategically about how the code you ship drives business metrics. Looking to build something cool? Get started with the MongoDB for Startups program.
Built With MongoDB: Queenly
Built With MongoDB: Gryphon Online Safety
Built With MongoDB: ADEx
Anyone who has reviewed legal documents knows how tedious and time-consuming the process can be. In the high-stakes, detail-oriented legal environment, even experienced lawyers or paralegals can make mistakes. And those mistakes can be expensive. Enter ADEx . ADEx is an online legal document due-diligence platform that is transforming the way people interact with legal and financial documents. “Computers never get tired, no matter how many pages your legal document contains or how dense its language,” says ADEx Co-Founder and CTO Apoorv Khandelwal . “Our platform can abstract your legal documents faster and more reliably than a paralegal.” The company has hosted more than 7 million contracts and partnered with large companies including Salesforce, Box, and Colliers International. As part of our #BuiltWithMongoDB series, we spoke with Apoorv about the company’s growth, its tech stack, and his experience scaling with MongoDB. MongoDB: What's ADEx's tech stack like? Apoorv Khandelwal: For our back end, we use the Java-based Play and Spring frameworks. We use Angular for the front end and Electron for the desktop app. For various predictions, we have Python Flask applications, and the deep learning models themselves are trained with TensorFlow and Keras. Our cloud provider for servers and application deployment is Kubernetes. We use various AWS services for storing clients’ legal documents, machine learning models, and other files. But the majority of our application data — ranging from contract summaries to our provision library to user events — is stored in MongoDB. MongoDB: How did you decide to use MongoDB? AK: Having worked at Amazon as a software development engineer, I was familiar with SQL databases and Hadoop. The team focused on machine learning, so its input data formats and sources were constantly evolving. My experiences showed me the pain associated with keeping SQL schemas up to date. When the choice came for ADEx, it was clear to me that we couldn’t use SQL. My experiences in successful startups showed me how we could successfully leverage the flexibility and scalability of MongoDB. I had worked before with Dynamo and other NoSQL platforms, but we didn’t want to get tied down to specific cloud providers. There were conversations about graph databases such as Neo4j as well, but they were not ideal for the majority of our queries that execute bulk data scans or do not start from a known data point. In the end, MongoDB’s flexibility and large community support made it the best choice. Later, upon joining the Techstars Accelerator in 2019, we were able to get credits through the Techstars and MongoDB for a startups partnership. We worked with a technical advisor at MongoDB to set up private connections from our applications. The learning curve was very short compared to other databases I had used; the basic concepts were clear, and the documentation guided me through the more complex data modeling and architecture decisions. Between features such as end-to-end encryption, auto-scaling, and automated backups, much of the basic database management work is now handled by MongoDB Atlas. MongoDB: How has MongoDB been for you as you've scaled? AK: With Atlas, I don’t have to worry about scaling anymore. Given how intuitive and easy to use it is — especially with the metrics and visualizations — it has solved a bunch of problems. I don’t even have to think about storage, because the database capacity automatically adjusts based on current data usage. Often for SQL, a team of database engineers may be needed for managing and running the database. With Atlas, we don’t need any dedicated person at all. We’ve been pleasantly surprised by the gentle learning curve while gradually utilizing more MongoDB features. For example, as we’ve introduced more-sophisticated use cases in our products, and we have enjoyed using MongoDB’s powerful aggregation framework to offload data processing from our application servers. We have an M30 cluster for cloud, and M20 for QA. MongoDB: What advice do you have for developers hoping to someday become CTOs? AK: Three things. First, get prior experience at a successful startup with a small engineering team. You will witness firsthand the growing pains a CTO has to deal with. These practical lessons can be invaluable for your own venture. Second, act as a filter between the business and technical teams. Imagine filling a small plate with food from a giant buffet. In a startup, the technical team has a limited capacity with which to build features or maintain the product. You should actively filter the flow of incoming ideas and features. Prioritizing the most crucial ones will prevent overflowing the technical team’s capacity while ensuring maximum value for customers. And third, get good technical mentors. It’s difficult to design sufficiently abstract data models that anticipate all potential future pivots. But a good debate with mentors can save plenty of technical debt later on. The first years were hard for me until I got technical mentors, such as Lalit Kapoor and Mihai Strusievici through Techstars. Looking to build something cool? Get started with the MongoDB for Startups program.
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. Looking to build something cool with MongoDB? Get started with the MongoDB for Startups program.
Built With MongoDB: Stoovo
When Hantz Févry and Pierre Mombeleur first met, they wouldn’t have guessed they’d one day become co-founders. As students at the same high school in Haiti, they weren’t particularly close. There was no noticeable chemistry when they faced off in a music competition either, and they maintained only a passing acquaintance on Twitch. But both attended college in New York. At the time, Hantz’s checking account was constantly overdrawn, and it was harder than he thought to pick up short-term work. He and Pierre started talking about ways to help gig workers maximize their income by providing intelligence about how and when to use platforms such as Uber and DoorDash. They kept working on that idea even as both got jobs at Google. In 2015, the pair met Semih Korkmaz, who became their CTO, and in 2018 they launched Stoovo , an app to help gig workers maximize their income. Stoovo now covers 6,000 platforms used by gig workers to find jobs, and has 17 employees. Just last week, the company announced that it had raised a $2.4 million seed round from 500 Startups, Alpana Ventures, Plug and Play Ventures and Watertower Ventures. In this edition of #BuiltWithMongoDB, we talk to the Stoovo team about building for the gig economy, immigrant entrepreneurship, and their experience growing with MongoDB for Startups . How did you keep Stoovo going while you were at Google? Hantz: There is a big misconception among venture capitalists that you need to be working full-time on your startup. That is not true in the case of immigrants. I’m an immigrant, and don’t have my aunt’s couch to sleep on. I don’t have this famous garage in Silicon Valley. So I basically had to work two full-time jobs. After working until 5 pm for Google, I started working with Semih, often until three or four in the morning. What is your vision for Stoovo for the next few years? Hantz: You have three main players in the gig economy: the platforms, the requester, and the supplier. The problem is that the worker, or the supplier, is left completely alone, because the platform is optimizing to meet the demand of the requester. We want to shift that optimization to help workers maximize their income for each hour worked. We want to give them financial stability through income boosting and income smoothing. Without Stoovo, workers are on their own trying to figure out if their time is better spent on DoorDash or Uber Eats or Postmates. They realize that if they blindly follow the direction of those platforms, they may not make enough money. The average gig worker uses three platforms, and shuffles arbitrarily between them, or relies on word of mouth, which is not really optimal. We tell gig workers which platform is best for them at any given time, and when to take a break. We go even further to help with financial management. We envision another type of banking for gig workers, where we not only store the money, but we’re better adapted to their realities. How does the typical gig worker use Stoovo? Hantz: We have one user, Lionel, who is an actor and does gig work to help ends meet. Without Stoovo, he was trying to use Uber sometimes, sometimes Postmates. Sometimes he made money, sometimes he didn’t. With Stoovo, he knows exactly how to shift between his acting career, and exactly what to do and how many hours he needs to work. Another user might rely more on the finance side. We have one user, Megan, who relies on the card for a cash advance. At first we were thinking that gig workers would use the cash advance to pay for gas. But when we looked at the transactions, a lot of them were fast food. Megan explained that gig workers often don’t even have a sufficient cash flow to buy food. This is why we built the two products together. We help you plan your day to maximize your income and we provide you with cash flow if needed. How have you built your tech stack to enable this? Semih: Stoovo is a very distributed system and works with many different partners, especially geospatial data providers, so our stack is a little bit heterogenous. On the application side we use Node.js, and MongoDB is our database platform. On top of that, of course, we have lots of Python scripts running. How did you select MongoDB as your database solution? Semih: We did a few prototypes with relational databases, but there were so many changes – not only on our side, but at our data partners – that we weren’t able to stick with a schema. And changing the schemas in our applications was almost completely eliminating our chances to work in an agile manner. We were really impressed with some of the capabilities of the graph databases, but you can always represent a graph in a document format. That’s when we realized we would go with NoSQL. After that, it was easy to choose MongoDB. What has it been like scaling with MongoDB? Semih: MongoDB Atlas made our life much, much easier. If you’re a startup, when you first start with a database, you want to start small. You have to keep your costs under control and your maintenance low. Then you need to scale up, and you see many startups fail to do this. Thanks to Atlas’ sharding system and its scaling system, which is automatically handling each replica’s scaling, we were having no problems at all with this, and we were easily able to scale. What are some of the features of MongoDB you find most valuable? Semih: We are rapidly developing many machine learning models, and they can be changing all the time. Those can create a new collection or change an existing collection, and change the access patterns. When this happens, indexing becomes really important. MongoDB Atlas helps us in two ways. One is that it gives us real-time alerts when our interaction pattern has changed. And, it suggests what the index should be. Then we can say, “Yes, please go ahead,” and apply this index on a rolling basis, and that makes life really easy for us. There is so much happening in the gig economy. What are your thoughts on how Stoovo fits into the future of the sector? Pierre: There’s an increasing amount of pressure for platforms to make sure workers’ rights are respected. We want companies to really give workers context into their work and be able to use data to their advantage, rather than holding onto the data and only using it themselves. Hantz: If you talk to someone from Gen Z, they don’t see themselves working for a big corporation from nine to five. There will also be a lot of automation and a lot of displacement of jobs. So a lot of people will jump into the gig economy, and they’ll need two things: They’ll need to make sure they earn enough, and they will need a financial system built for gig workers. This is exactly where we’re trying to position Stoovo. Looking to build something cool? Get started with the MongoDB for Startups program.
Built With MongoDB: Journey Foods
Serial entrepreneur Riana Lynn has been building the future of food for more than a decade. While in graduate school and researching data and genetics at the University of Chicago, she launched one of the nation’s first juice bars which gave her an inside look at the supply chain issues plaguing the raw food industry. After that, Riana continued innovating in the sector: She built and sold two other companies, worked in venture capital, and, in 2018, launched her most ambitious startup yet – Journey Foods , a machine learning-powered software platform for food companies. Just three years after its official launch, Journey Foods has raised $2.5 million from investors across three continents. It has partnered with global consortiums such as Future Food Network at Stanford, FoodTank, and University of Chicago on sustainability and data, and it now has more than 130 companies as customers, including Ingredion, one of the world’s largest ingredients companies, and Unilever. For this edition of #BuiltWithMongoDB, we speak with Riana about food technology, scaling an artificial intelligence platform, and the future of food. You have worked in food tech for most of your career. What specifically inspired you to start Journey Foods? While I was working in venture capital, I wanted to find a product that could help us track an unprecedented amount of data about food: everything from optimizing the supply chain to price and nutrition. We ended up building it ourselves using Google spreadsheets and a few APIs. I presented some of our early work in March 2019 to 1,500 food companies at a conference in San Francisco. Some of them asked us if we could apply our algorithms to their food products and work with their internal teams. That’s when we decided to take our work and turn it into a SaaS offering, and Journey Foods was born. There are so many problems we need to tackle to provide everyone with healthy and affordable food. What's your vision for Journey Foods? We consider ourselves a technology company for the food industry—whether you are trying to source ingredients, optimize your supply chain, or get consumer insights as to how your product will perform in the market. We aspire to be the leader for integrations in the food industry. We’ll be able to provide additional services that will help our customers scale and improve their portfolios much faster. Right now we are trying to focus on developing our service to accurately provide nutrition insights, sustainability insights, and help save our customers money. We are prioritizing partnerships that will help us build out a big and dynamic ecosystem. How did you decide to start building with MongoDB? I wanted to make sure we could create something that was scalable, not only for startups but also for enterprise customers. In the first six months, we built the product on top of the Google Cloud Platform, a low-code app called Bubble, and a bunch of APIs. But our enterprise customers were using SAP and Microsoft Dynamics, and I realized that in order to provide offerings for these companies, we needed to have databases that could work at that same scale. We also needed better security for our customers, which is especially important in the food industry. We looked at the tools the best software and data companies were using. We didn’t want clunky integrations that slowed us down. We’re also a design-heavy firm, so we’re thinking about the user experience as well. Given MongoDB’s seamless user experience, ease of scalability, and stellar recommendations from other companies, we ended up building with MongoDB. What's your favorite MongoDB feature? This might not count as a feature, but the support and the follow-up we receive from MongoDB has been consistent and persistent. Our developers appreciate how easy it is to use the platform, and how seamless it is to share and collaborate on different things. We also take advantage of many of the webinars, courses, and training programs that MongoDB offers. We want to move into more automation, machine learning, and artificial intelligence functionality, and we’re interested in seeing how MongoDB will help us evolve in that direction. Looking forward to the next decade, what do you see as the biggest opportunities in the future of food? I see two things. One has to do with overall nutrition and chronic disease. Over the past few years, we’ve seen dire numbers on chronic disease in every country in the world. Food technology is going to help improve those numbers. Second is that with the pandemic, we went back to a lot of deleterious environmental practices in the supply chain, just so that we could meet demand in a quickly-changing world. The environment, along with affordability, is a very big interest both for companies and people. And we are bringing in data that is relevant to the biggest problems we see in the world with food, affecting the livelihood of people across the world. For us, our competitive advantage lies in being the one-stop shop that integrates across many markets and partners, and that can drive the most actionable experience for our customers so we can define the future of the food industry. Looking to build something cool? Get started with the MongoDB for Startups program.