Siya Raj Purohit

19 results

Built With MongoDB: Antler

Antler is a global early-stage venture capital firm that invests in the defining technology companies of tomorrow. The firm has offices in 13 cities worldwide, across six continents. Founded in Singapore in 2017, Antler is on a mission to fundamentally improve the world by enabling and investing in the world's most exceptional people. Since its launch, Antler has invested in and helped build over 250 companies. Antler enables exceptional people to build impactful technology startups by building complementary teams, supporting the teams with deep business model validation, and providing a global platform to scale their startups — and that’s why we’re thrilled to announce the firm’s partnership with MongoDB for Startups . We recently touched base with Antler Partner Björn Lindfors to talk about entrepreneurship, building and managing new companies, and partnering with MongoDB. Björn arrived at Antler after an incredible entrepreneurial journey of his own that included launching a web design studio to fix “crappy websites” during his university days, learning the ropes at Google, and serving as an executive of two companies in Singapore. Antler has raised $78 million and has offices in 13 locations across the world. MongoDB: How does Antler differentiate itself from other accelerator programs? Björn: We’re technically not an accelerator. We’re even earlier than that: we bring together between 70-100 top performers who may not even have an idea yet for phase 1 of the program, where they collaborate with other aspiring entrepreneurs to come up with an investment-worthy idea they can present to our Investment Committee. We’re very hands-on in our approach to venture building: We have a range of technical and business advisors who coach the entrepreneurs and follow their progress. For example, I’m still in weekly contact with many companies that we invested in during our 2018 sessions. We’re builders ourselves, and we want to keep adding value and serving as sounding boards for our community members. MongoDB: What do you recommend to your CTO founders when building out their companies? Björn: The first thing I encourage them to understand is that product isn’t everything. Building your product shouldn’t distract you from other things that are incredibly important for a successful business — for example, how to effectively run an engineering organization, how to hire good people, and how to make sure that your team members are constantly happy. The real struggle for me in transitioning into a CTO role at one of my former companies was the management aspect. I had completely underestimated the human elements and how much time and effort you need to spend to ensure that people are feeling happy and productive. I always tell people to focus more energy on that. MongoDB: Have you personally used MongoDB in your past companies? Björn: Yes, I have used MongoDB quite a bit, especially during my consulting years. If you’re building something quickly and don’t quite know where to start, MongoDB is the perfect partner. MongoDB is convenient and flexible enough to adjust as you transform your prototype into something more permanent. The first iteration of whatever you build is likely 80% wrong anyway, and you don’t want to be stuck with something clunky. For most consumer apps and business use cases with simple business logic, MongoDB works great. MongoDB: How has the Antler community responded to the MongoDB for Startups partnership announcement? Björn: When it was announced on our internal Slack group, which consists of thousands of people from our alumni and portfolio globally, there was a lot of excitement. MongoDB is part of the default stack that startups use to build businesses. I get questions from founders constantly about how to build, and I constantly advise them to use MongoDB. There’s no point in people teaching themselves something else for the purpose of building when MongoDB is the perfect default kit. We are excited to deepen the partnership over time. MongoDB: Why should aspiring founders work with Antler? Björn: If you’re driven, curious, and passionate about changing the world in some small, weird, and wonderful way, we are the right fit for you. We back founders working in all sectors and provide the right resources, mentorship, and community to help get their businesses off the ground. MongoDB: What do you think the future of Antler looks like? Björn: I think it could evolve in a few different ways. If you look at the entire investment landscape, at least here in Singapore and Southeast Asia, the seed investment sector has become very competitive. Seed investors are competing for deals and therefore have to provide strategic value along with funding to their portfolio companies in ways that they didn't have to before. Good entrepreneurs now have options, so the pressure is on investors to provide a lot of additional strategic value. Similarly, we’ll keep innovating on the services we can provide founders to help them be successful in this changing tech landscape. Interested in learning more about MongoDB for Startups? Learn more about us here . Special thanks to Andrew Bell for his help in compiling this piece!

June 16, 2021

Built With MongoDB: Vectorly

When Sam Bhattacharyya spent time in the Peace Corps as a teacher in Mexico, he learned how much of a barrier the lack of internet bandwidth was for his classes. The students simply did not have the resources needed to take advantage of online learning, which was a problem Sam soon became fixated on. Years later, Sam founded his company Vectorly with a goal to fix that bandwidth issue via an AI-based video compression solution that streams low-resolution videos and turns them into a high-definition viewing experience. Vectorly is a software development kit (SDK) that companies can integrate into their video applications. Vectorly released its minimal viable product (MVP) for use by early customers in February 2021 and has a total of 20 companies that are actively using the product. In this edition of #BuiltWithMongoDB, we talked with Sam about how Vectorly’s software works, how he got started with MongoDB for Startups, and the future of this fast-growing industry. MongoDB: What's Vectoryl's mission? Sam: We’re building a technology that uses artificial intelligence (AI) to upscale and enhance video in real time on users’ devices, as they watch it. So, what that lets a user do is stream low-resolution video content and watch it in high definition. We have about 100 AI models on our server. Most of them are for AI upscaling, for different kinds of content and different quality levels. Based on feedback from customers, we've also been building AI filters for, say, virtual background replacement. All that data is loaded in real time from the server every time you load the library. With our SDK, you specify that you want to use this AI filter on that library, and you have an API token that calls our API and that returns the AI model in real time to your device so you can watch the upscaled video. AI takes some computing power, which can be a concern especially on low-end devices, and we’re conscious of that, so we pay close attention to performance and frame rate to make sure our AI models do not overload the devices users are working on. MongoDB: What are some of the use cases for Victory? Sam: The first is to think of a user that is watching Netflix with a slow internet connection. Because the network is so slow, that user’s going to end up with a low-resolution version of the video. But we have AI filters that can pop in and start to upscale and enhance the video and make it look as if it’s high definition. The other use case is around video conferencing, where all kinds of things can affect call quality or user experience, from background noise to blurry video. You can use AI to correct any of those issues that come up. MongoDB: What does your tech stack consist of? Sam: Our product is a software library, which is for the web, and it’s all built in JavaScript. The main JavaScript functionality we’re using is called WebGL, which is a graphics pipeline that lets you access the GPU on devices. We have a bunch of AI models on our server, which are just numbers stored in JSON files. Our SDKs load the AI models in real time, and we use MongoDB to track and store event data, as well as basic metadata. MongoDB: How did you choose MongoDB? Sam: I've been using MongoDB since I started programming in 2012. Although the first programming course I took used the LAMP stack (Linux, Apache, MySQL, and PHP), SQL seemed unintuitive, and the LAMP stack in general just felt bulky. When I started my first personal programming project, I looked for alternatives, and I found this new thing called the MEAN stack (MongoDB, Express.js, AngularJS, and Node.js). I thought it was the greatest thing in the world that you could use JavaScript in the front end and the back end, and that you could even use JSON like notation for the database. Having a full JavaScript stack made so much sense. Every web development project I've started since has used the MEAN stack. When it came time to hack together the first version of Vectorly, MongoDB was our first choice for the database. MongoDB: How has the experience been working with MongoDB? Sam: It’s been fantastic. We had to come up with this model of tracking users and usage of our platform in a very short amount of time, because the first version we released had no tracking whatsoever. One of the things that saved us a lot of time was the MongoDB Charts function, because it really allows us to track what we’re doing. It was super quick to set up. Looking to build something cool? Get started with the MongoDB for Startups program.

June 9, 2021

Built With MongoDB: Phable

Hundreds of millions of people across India face chronic diseases. India has the second-highest number of diabetics in the world, and citizens with high blood pressure, thyroid conditions, and other chronic ailments are underserved in the country because there’s no robust system in place governing how the treatment and diagnosis will be handled. Given the lack of a proper infrastructure, diseases slip under the radar because they’re not caught early on. That’s where Phable comes in. According to TechCrunch , "Phable has created a more transparent and real-time communication channel that allows a doctor to nudge their patients to take their medicine on time, and make any necessary changes to the lifestyle or medication cycle, or request a follow-up appointment. The app itself can be used for tele-consultation, the demand for which has skyrocketed in recent quarters as coronavirus forced people to stay indoors.” The company, which has raised $12 million in funding from India’s Manipal Hospitals and venture capital and investment management firm SOSV, reaches 350,000 patients, 5,000 doctors, and a staff of 100 people across Chennai and Bangalore. In this edition of #BuiltWithMongoDB, we talk with Phable’s Creative and Marketing Consultant Ganesh Chandrashekar and Engineering Manager Venkatesh Walajabad about what drives their business. MongoDB: What is the Phable product offering right now? Ganesh: We currently have two products: patient facing, and doctor facing. For patients, we give them a sense of their everyday health and handhold them through the process of understanding their first symptoms, getting prescribed a treatment plan, and recording their ongoing lifestyle changes. We help map and manage those lifestyle changes at a fundamental level, while giving them intelligent insights to help them make small tangible changes to everyday habits. We also connect them to doctors in a more real-time manner, so doctors have deep visibility into a patient’s health, and the patients can get personalized recommendations from doctors. While our focus is on preventive and personalized care, we have some value-added services that ease our users’ journey. They can order medicines from the app, schedule video consultations with doctors, and request lab tests directly. We’re building a broader health tech ecosystem where we are able to partner with the relevant companies — including some leading names in health device manufacturing, insurance companies, and medicine providers. For doctors, we’ve built a full product suite with a decision support system and EMR. So we’re able to help them digitize their practice, prioritize and process patient data, simplify clinic management and build better relationships with their patients. MongoDB: Has COVID-19 impacted product adoption or any of the features that are being used? Ganesh: Our growth has been in parallel with the pandemic over the past year. The pandemic gave a sense of urgency, and put the spotlight back on healthcare and understanding health at a more granular level. A lot of the new features we have — especially virtual doctor consultations — were developed at a breakneck speed to cater to users at home during the pandemic. MongoDB: You released the video consultations really quickly, especially given the uncertainty surrounding COVID-19 in 2020. How did you approach that from the technical side? Ventkatesh: Because there were a lot of unknowns in building this, we wanted to experiment and release in certain phases so we could gather feedback and then add features on top of that. We are quite nimble at Phable as a whole: we started with consultations, moved on to an ecommerce platform, and then added wallet features. Similarly, for the video consultation product, we released in chunks — experimenting with users, analyzing their usage, and then shipping the feature more widely. MongoDB: How did the team decide to build with MongoDB? Venkatesh: The decision for MongoDB happened right from Day 1, because the team wanted to go with a MEAN [MongoDB, Express.js , AngularJS , and Node.js ] and MERN [MongoDB, Express.js, ReactJS, and Node.js] stack. Initially we used the community version, and then early last year we shifted to MongoDB Atlas. We wanted to use all the clustering capabilities and backup support, in addition to the profiling and detection of slow queries. We use a lot of those features to figure out where our bottlenecks are. We got some credits through MongoDB for Startups, but MongoDB Atlas is still on the more expensive side for us. Even though it is a little expensive, the advantages that we get from MongoDB Atlas far outweigh the cost. We use AWS for our server needs, and we have a fair bit of integration between AWS and MongoDB via VPC peering so all data is more secure, in addition to the encryption MongoDB provides. MongoDB: How is your engineering team structured? Venkatesh: There are 18 engineers on the team — and we’re trying to add more so we can launch more features and expand into new markets. Readers take note: We are hiring engineers for our India offices! MongoDB: How has scaling with MongoDB been, especially given how much you've grown during COVID_19? Venkatesh: MongoDB Atlas takes care of all the autoscaling for us. We worked closely with a consultant to figure out what minimum and maximum instances we need for our clusters, and then we rely on MongoDB to do the autoscaling. During a calmer period, MongoDB Atlas scales down perfectly well and reduces the costs; in a high-growth period, it scales up to accommodate for the traffic. We love that it automanages things so we don’t have to worry about it day to day. Because MongoDB’s features take care of most of the work, we don’t need a dedicated person to oversee this — we plan a few months ahead, and then we let MongoDB take care of the work. Looking to build something cool? Get started with the MongoDB for Startups program.

June 2, 2021

Built With MongoDB: Milky Way AI

Sagar Setu received his PhD in helicopter flight dynamics and has a fascination with deep learning and integration within the field of aerospace. However, helicopter flight dynamics is not what Sagar is involved in today. Through Entrepreneur First , an international program that helps entrepreneurs launch companies, Sagar met Eunice Wong , a fellow aspiring entrepreneur, who introduced Sagar to the world of retail, which he calls a “fantastic playground” for any engineer to be involved in. The pair founded Milky Way AI, with Wong as CEO and Sagar as CTO. Milky Way AI is designed to empower the largest retailers and brands globally with real-time visibility into how their products and their competitors’ products are being merchandised across thousands of stores. In this edition of #BuiltWithMongoDB, we chat with Sagar about the ways Milky Way AI creates opportunities for retailers, his favorite MongoDB features, and how the competitive AI industry keeps him motivated. MongoDB: What does the product look like now, and how does it work? Sagar: Our flagship product is called InstaShelf. It’s a mobile app that we put in the hands of distributors and merchandisers. When there is a person stocking the shelves and we put the app in the hands of that person, they are able to snap a photo, which then goes through our proprietary computer vision engine. This generates a variety of insights that are valuable for both the distributor and the brands. We are looking into how we can share this same data with and make it equally valuable to the retailers. We developed this product over the last year and launched our beta three months ago. Since then we have gotten quite good traction in terms of users in a number of countries that are deploying the product. MongoDB: Let's talk about that traction. How far along are you? Sagar: We started in January with a 15-store pilot for Kelloggs in Singapore. We have deployed across 150 stores now, and we are set to deploy across a few hundred more in Malaysia and the Philippines. By the end of next year, we hope to be in three more countries — just with Kelloggs. The typical number of users for each of our pilots is around 15 to 20 merchandisers visiting between 50 and 60 stores. In a typical audit, the user takes 10 to 15 photographs and our AI identifies what's on the shelf from these pictures, reporting on key metrics such as a brand’s share of shelf compared with a competitor brand, products that are out of stock, product placement compliance, and so forth. MongoDB: What does your tech stack consist of? Sagar: The web and mobile components of our solution are built using MongoDB, React Native, React, Node.js, and Python Flask. The computer vision pipeline is built on both TensorFlow and Pytorch. We use MongoDB for all our database requirements — transactional and analytical. Our top criteria for choosing the tech stack were proven scalability and stability, and a wide developer pool. It was important in the early stages to keep the team lean and the product flexible, and the choice of MongoDB Atlas turned out to be a great one. The support for being schemaless was crucial in allowing us to stay nimble as we learned the nitty-gritty of the domain. With features such as triggers and BI Connector, we could orchestrate various components of the solution right from the Atlas GUI, saving us hundreds of working hours. MongoDB: What are some of your favorite features in MongoDB? Sagar: My favorite feature is the support with autoscaling, which is the primary concern if you’re building anything into production. I’ve never had to worry about that. I don’t even think about it; I have just turned the features on, and it allows so much creativity. With MongoDB Atlas, I have peace of mind. MongoDB: What is something that you are learning right now? Sagar: Learning is a constant, working in the field of AI. A wonderful plus point is you always have so much competition: there might be a paper tomorrow that basically undoes everything you’ve done — something comes out that is far superior to the method you just took two months to deploy. So I’m always reading, learning, and trying to improve our solutions. MongoDB: What’s one of your favorite books? Sagar: The Selfish Gene . It’s not exactly technical, but more on the scientific side. That’s more of my kind of read. I really like the thought process the book instills in you. It gives you an understanding of the world — the good, the bad, and learning not to take things personally. Looking to build something cool? Get started with the MongoDB for Startups program.

May 26, 2021

Built With MongoDB: Italic

Derek Tu and Jeremy Cai , two high school friends from the Chicago suburbs, began aspiring to become entrepreneurs at a young age. Their pursuits took them to Babson College, where they overlapped until Jeremy received a Thiel Fellowship and dropped out of school to build his first startup. Now, the two friends have teamed back up to create Italic , a membership-based marketplace, with Jeremy as Founder/CEO and Derek as Product Lead. The game-changing Italic platform offers manufacturers the chance to sell their products directly to consumers and reach a global customer base. Since its launch in 2018, the company has raised $15 million and given consumers the chance to shop unbranded quality goods at prices 80 percent lower than what comparable brands would ordinarily charge. Italic launched with a waitlist of more than 50 thousand people, and it’s also built a team of 54 employees across the world. In this edition of #BuiltWithMongoDB, we talk with Derek about building the new “everything store” and his experience building a game-changing ecommerce platform with MongoDB. MongoDB: What was the original vision for Italic, and what does the product look like now? Derek: The original vision for Italic was pretty simple in my opinion. It was to make good on the original promise of direct-to-consumer (DTC) ecommerce, which is to cut out the middleman, sell goods or services straight from the source, and pass the margin savings back to the customer. We strongly felt that existing DTC incumbents weren’t upholding this promise and had become themselves the middlemen in this entire equation. We eventually found that we could best deliver on this promise by operating a subscription model in which we charge for a membership that grants customers access to our entire product offering. By doing that, we’ve been able to drop the prices on products to a level where we are essentially passing all the savings directly to the members and where we profit only from the annual subscription fee that our members pay. MongoDB: What does the tech stack consist pf at a high level? Derek: We’re running on a Jamstack , consisting of a Next.js framework on the front end with deployments handled by Vercel. Our back-end system consists of Node.js services that interact with our MongoDB cluster via an Apollo GraphQL client. MongoDB: How did you decide to start building on MongoDB? Derek: Prior to MongoDB, we used Shopify directly as our pseudo-database, but when we went to launch our membership app, we realized the need to create and manipulate data outside Shopify. There was pressure to launch and test the membership app as quickly as possible, so we tried to find a database system that’s highly performant and easily scalable, yet quick to implement. We needed to start deploying features ASAP, because time was a luxury we didn’t have. That’s where a nonrelational database such as MongoDB helped, because we didn’t need to spend hours upon hours finalizing a data schema with primary and foreign keys first. We were also looking to ingest data from Shopify, so not being bound to a certain table structure allowed us to save time on ETL. We tried hosting a Mongo cluster ourselves at first but quickly realized we needed a fully managed service that could abstract out DevOps for us. Ultimately, that’s why we started using MongoDB’s Atlas solution. MongoDB: As you've grown over the past two years, how has it been working with MongoDB? Derek: The best web services are the ones you set up once and they keep running in the background with minimal upkeep. That’s how I’d describe MongoDB Atlas. I honestly can’t remember the last time I had to log into our dashboard to resolve a database-related issue. When we started, we leaned heavily on MongoDB’s technical support to help answer our questions and triage some of our issues. And of course, the startup credits that came with being a part of the YC alumni network definitely helped, because they provided us the opportunity to test the service out before truly committing and paying for it. MongoDB: As a product lead, what resources do you use to upscale in your job as you grow in your career? Derek: Honestly my engineering peers have been the most valuable resource for me as a product manager. Just from answering my questions and through candid discussions, they’ve taught me more about building products than any bootcamp or college degree ever could’ve. And, as I’ve progressed in my career, I’ve stopped asking them how the software is being built and started asking them instead why the software is being built a certain way. I’ve learned over time that feature limitations often stem from how underlying technologies are selected and implemented. Therefore I’m a firm believer that all successful product managers need a deep understanding of systems design. MongoDB: What is the last good technical book that you read or podcast that you listened to? Derek: Not super technical, but I’m currently listening to All-In with Chamath, Jason, Sacks & Friedberg . It’s refreshing to hear their unfiltered, personal takes on major events in the public and private markets. In terms of more technical reading, Wiley’s textbook Systems Analysis and Design is my reference for anything related to systems design. I’ve also been a huge fan of Glossier’s tech team from the early days and have learned a lot from studying them. This article from an early team member provides an in-depth walkthrough of their data pipeline and shows their deliberate efforts to invest upfront in technology that paid dividends for them later on. MongoDB: Who are some technical mentors that you admire for their technical and product management skills? Derek: We have a large roster of angel investors who are seasoned tech executives and founders at hyper-growth startups, public companies, and everything in between. I won’t name drop them all here, but they’ve all been instrumental to our success to date. We’ve been able to lean on every one of them for advice and mentorship from time to time. Looking to build something cool? Get started with the MongoDB for Startups program.

May 19, 2021

Built With MongoDB: Memora Health

Always interested in healthcare, college roommates Manav Sevak and Kunaal Naik spent quite a bit of time exploring the various challenges that exist in the area of patient communication and discovered a common problem: patients often experience a profound sense of confusion about their care after they leave the hospital, along with a great sense of isolation. Navigating complex medication regimens, instructions, dietary restrictions, and doctor’s orders without strong support tools was often impossible for patients, resulting in billions of dollars in preventable healthcare expenditures every year. Joining forces with Nisarg Patel , the roommates set out on a mission to rewire America’s healthcare systems with modern technology so that clinicians could interact meaningfully with their patients and patients could access healthcare information as easily as they could text their families and friends. Three years later, the team has built a comprehensive platform that facilitates how care is delivered outside the four walls of the clinic. The trio joined Y Combinator’s winter 2018 cohort and has grown significantly since. Their company, Memora Health , has now raised $10.5 million from leading investors, including Andreessen Horowitz, and is used by more than 50 healthcare organizations across the country. In this edition of #BuiltWithMongoDB, we talked with Memora Co-founder and CTO Kunaal Naik about building a healthcare technology business with MongoDB from day one. MongoDB: You've said that you got into health tech to make an impact in an industry that is lagging in its use of technology. What solutions does Memora currently provide? Kunaal: The healthcare industry is seriously lacking in its adoption of technology that can really improve how care is delivered. Although this may seem like a simple problem to solve on the surface, our team has really discovered the nuance that goes into making sure we are building tools that truly empower doctors and are easy to use for patients. Memora provides a full suite of modules that simplify how patients and doctors interact. This ranges from remote monitoring and messaging programs that automatically track a patient’s health status to tools that automatically document notes in a patient’s medical record for clinicians to easily identify which patients may need additional care. We’ve deployed our platform for several hundreds of thousands of patients and more than 50 healthcare organizations across the United States and Canada. MongoDB: how has COVID impacted the adoption of new health tech solutions? Kunaal: The pandemic has really accelerated how quickly large healthcare organizations — from health systems to insurers to life science companies — are adopting and implementing Memora. For the first time, it seems as if these organizations are realizing the need for large-scale change in how they reach and care for their patients. We are seeing significant adoption of the platform, which in turn has only given us more insight into how we can continue growing the platform to power more core functionalities inside of health systems. An example of this is a situation where hospitals needed to build virtual waiting rooms to properly enforce social distancing and safety over the last year. Memora’s core workflow technology was used to build text-based screenings that allow patients to be screened for health concerns prior to a visit, assess acuity to determine if a visit can be conducted virtually, and enable patients to wait in their cars and automatically get notified when their doctor is ready to see them. We’re seeing that these kinds of digital workflows are actually easier for patients and clinicians and will likely be used even after the end of the pandemic. The core design of our platform has enabled us to support a broad spectrum of care delivery use cases like this, rather than just being a point solution. MongoDB: What's your vision for the product? Kunaal: Memora is a product-driven company, so the technical decisions we make significantly impact our ability to differentiate ourselves and provide a truly intelligent, scalable platform. At scale, Memora is building an operating system for a new kind of care delivery — a platform that intelligently digitizes existing physician workflows and provides the entire infrastructure for how clinicians reach their patients and patients are cared for outside the four walls of the hospital. The infrastructure layer we are building for healthcare organizations will power everything from messaging to symptom management to remote monitoring to reimbursement. The platform is always learning — each encounter and physician workflow makes us smarter and allows us to deliver a higher standard of care to patients. Over time, we want to increase Memora’s predictive capabilities. We have built a robust metrics infrastructure that intelligently adjusts message timing, frequency, escalations, and more for both doctors and patients. Our integration with MongoDB has really helped scale all of these solutions, especially given how intensive they are from a data and computation perspective. MongoDB: What does your tech stack consist of? Kunaal: The core of our platform runs on JavaScript, and we use React Redux with TypeScript on the front end. On the back end, we’re using Node.js hosted on Google Cloud (Kubernetes). That’s plugged into MongoDB. In terms of ease of use and scalability, Node.js works very easily with Kubernetes. MongoDB has been instrumental at powering data storage in a way that is scalable and HIPAA-compliant. Our natural language processing engine is primarily written in Python, which has enabled us to implement a series of microservices. MongoDB: Why did you choose to build with MongoDB? Kunaal: When we were launching the core platform, we found the compatibility between Node.js and MongoDB to be very easy to use. This is in contrast to some SQL databases where you have to already be deeply knowledgeable about tables and indexing before you can get started. For our engineering team, this simplifies our onboarding process as well and allowing our engineers to work across the entire stack pretty quickly. As adoption of our platform started to scale, we made a conscious decision to stick with MongoDB. From supporting indexing and joins, to simple replication management, to comprehensive and prebuilt backup infrastructure, MongoDB truly offers a set of services that make it easy for early-stage companies to get started but also scale. Our team has constantly mentioned how simple the MongoDB schemas are to quickly learn — and we’ve been able to get technical advice from consulting engineers such as MongoDB’s Abhinav Duggal when we need it. Because we operate in a highly regulated industry, MongoDB’s business practices related to providing Backend as a Service (BaaS) and service-level agreement (SLAs) are additionally compelling to make sure we can meet the security requirements of our customers. Looking to build something cool? Get started with the MongoDB for Startups program.

May 12, 2021

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 preview. 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.

May 5, 2021

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.

April 28, 2021

Built With MongoDB: Queenly

Queenly founders Trisha Bantigue and Kathy Zhou grew up in low-income immigrant families, trying to balance their cultural upbringing with their desire to fit into their American lifestyle. To earn scholarships to pay for college, they both started participating in beauty pageants. “Beauty pageants provide young women with the opportunity to kickstart their careers,” says Queenly Co-founder & CTO Kathy. “And one of the core parts of the pageant system is the evening gown — that was the spark of inspiration for us wanting to tackle the whole fashion industry.” According to Kathy, women in America — especially outside the coastal cities — end up attending around 15 special occasions a year. “Whether it’s prom, beauty pageants, or other formal occasions, women need cost-effective formal outfits,” she says. After working across leading Silicon Valley companies, Trisha and Kathy teamed up to build Queenly , a marketplace and search engine for the formalwear industry. “No one has created a robust search engine for formal dresses,” says Kathy. “People are picky about formal attire — there’s so much consideration that goes into it, from neckline to hemline, silhouettes, colors, and fabrics. We’re trying to build a marketplace, do complex queries, and provide personalized recommendations.” Queenly has 80,000 registered users and 50,000 dresses listed. The team of five ( which is hiring! ) is backed by Y-Combinator. We recently sat down with Kathy to learn more about how her pageant experience has informed her career, her experience with MongoDB, and the challenges in building a formalwear business. MongoDB: What was your first pageant experience like? Kathy: It was really eye-opening: I have always been a shy person, and my number one fear is public speaking. What people don’t realize about pageants is that along with having to learn how to dress well, you also have to be able to speak well. You have to learn to speak from your heart and to communicate well. Gaining the confidence and soft skills to answer those pageant questions has also helped me in my career, helping me grow from an engineer to engineering leadership. One of the most memorable questions from an early pageant was about what’s the most important thing you want to do in your pageant regime. I talked about how it’s okay for young women to both be nerdy and girly — you should be able to embrace all these different sides of yourself, and not fear falling into one box of being. I wish someone had told me that when I was younger. Now, I’m honored to be able to embrace both sides as a CTO, a Y-Combinator female founder, and a beauty pageant contestant. MongoDB: Building a two-sided marketplace is a challenge. What did the minimum viable product look like? Kathy: The MVP was very rough — I started by coding an iOS app part-time and during the weekends while I was still employed at Pinterest. The goal was to tackle the supply-side of the marketplace first to get people to upload dresses, so I optimized for creating a really easy dress-upload experience. You could only search for one size and one color at a time. Now, we’re using natural language processing query for search, and also a larger combination of different dress-type attributes. We’re also including reverse image search, and I’ve been working on tailored user recommendations. MongoDB: How did you make decisions for your technical back end? Kathy: Initially, we had very basic search and exploration using Google’s Firebase. It was very easy to set up and has a fairly good UI tooling, but its query capacity was something we were quickly outgrowing. At our stage of company, non-relational storages are a really great decision for the sake of speed and adaptability. As we’re working towards product-market fit, we need to move quickly in launching new user experiences and reworking old ones, so it’s important to have that flexibility in restructuring and reshaping our data. That’s when I went to MongoDB and realized that it was a really quick migration and had all the capacities and flexibility we need. MongoDB is great for JavaScript developers. I started with a background in front end, with a foundation in HTML / CSS and JavaScript, and it was very easy to pick up MongoDB. It’s also going to help a lot of emerging developers, and those coming out of coding bootcamps, get started on the back end more quickly. As people say, we were building the airplane as we were flying. We needed to move fast so people could access and search for dresses quickly. Many of our users are women who live in the Midwest and the South where they may not have amazing internet access, so speed and performance are pretty important. MongoDB: Are there specific features of MongoDB you're using, aside from Atlas? Kathy: The most important aspects are the core functionality and the monitoring toolings and dashboards. Those are useful and come right out of the box. I’ve been meaning to take a look at search capabilities — I think it’s cool that there are indexes right out of the box. We’re trying to adapt our product as it goes, and figure out how to tag and enable different attributes on a dress. MongoDB: What was the last good technical book or article you read? Kathy: I really enjoy reading the Towards Data Science publication on Medium. They do a good job of covering different use cases as well as making different fields algorithms and data science/machine learning concepts more approachable. Beyond that, I read several fashion magazines and pageant blogs because I think CTOs — and the technical side of the business — should really understand the users. I try to keep up with trends in fashion and retail to better understand the opportunity, and use that to influence how our product functions. Looking to build something cool? Get started with the MongoDB for Startups program.

April 20, 2021

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.

March 30, 2021

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.

March 16, 2021

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.

March 9, 2021