Software has been eating the world for quite some time.
In the last few years, this Mark Andreesen quote has been used by investors and tech leaders alike to describe various shifts that result from technological advancements. One of the most common transformations is perhaps the notion that Machine Learning is eating the world. In many ways, it’s true — advancements in AI and ML are staggering — people moved from being amazed by the ability to detect hotdogs in still images, to drivers struggling to stay awake while sitting behind the wheel of a Tesla driving on autopilot.
When a company has the resources, know-how, and talent needed to implement ML within its core business, its subsequent impact on business results is unquestionable. Unfortunately, this isn’t the case for most. Even in companies that already employ data teams who research and experiment, only 13% of ML projects reach the production stage.
(a shorter version of this article can be found here)
The challenge begins with the inherent differences between data science and software development. Building an AI/ML prototype is a task that resembles a scientist’s work in a lab; it’s based on notebooks, experimentations, comparison of results, etc., and it’s performed by data scientists.
On the other hand, software development is engineering work. Like a building being built, every new piece of software is added to the overall structure with predefined perimeters and integrations. It is designed to stay intact, and if something breaks, a roll-back is possible with a click of a button. There are no experiments in production, whereas data science is all about experimentation.
Unlike code-changes that don’t necessarily change how the program behaves, ML is based on real-life data that by definition changes the output of the model, and in some cases, even changes the model itself.
Creating a framework that supports these constant changes and bridges the differences between data science and software development requires data scientists to work hand-in-hand with developers (or data engineers, as they’re known today). The various stakeholders, which in some cases also include non-technical people like product managers, business-line owners, and other functions, don’t always have a common language. They do not share the same tools and they lack boundaries and clear division of responsibilities.
Solving the pains caused by the gap between data science & software development is not merely an operational promise. Data shows that AI companies have significantly lower gross margins, compared to their SaaS counterparts (50%-60% vs. >80%). Building an ML production environment with the right framework not only unlocks new business opportunities but also holds the key to improving the most important business KPIs that affect company value.
Enter MLOps.
Similar to how DevOps has been the enabler of scalability, allowing companies to innovate and release new versions faster than ever before, MLOps practices are being developed to support the challenges and growing pains AI companies face.
MLOps can be broadly defined as the convergence of technologies, practices, and processes to smoothly and scalably deploy, monitor, and manage ML models in production. Yet, though it sounds exceptionally simple, it is extremely complex to execute. The Internet is overflowing with blog posts, articles, research papers, podcasts, and videos explaining MLOps from various angles, so I’ll just sum up the challenges concerning building a good product —
First, rather than serving a single type of user, you must tend to the needs of a variety of stakeholders who must understand and use your product on a daily basis. As such, MLOps is intended to be the thread that ties the entire ML lifecycle together. Second, the ML landscape is still in a nascent stage, making designing and building a framework more like shooting at many moving targets rather than aiming at a sitting duck (see what I did there?). MLOps tries to reduce the time to market of ML products when paradoxically, the plethora of new tools and common practices create confusion that hinders the maturation of projects.
As an early backer of companies in the DevOps space including Coralogix, Epsagon, SafeDK to name a few, we’ve been closely monitoring the emergence of the MLOps space. Our first investment in the space was in DAGsHub, which is building a collaboration platform for data scientists, to address the pains data scientists face in the research phase. As more companies have gained ML momentum, we’ve been learning about the challenges of scaling ML production environments and were actively looking for the right team to back.
Welcome, Qwak!
As a seed investor, a key component in our decision-making process is Founder-Market Fit. Therefore, we looked for a team that had the best understanding of the problems customers face, the best knowledge of state-of-the-art offerings available in the market (by cloud vendors, startups, or open-source projects), and the ability to execute an ambitious vision. After reviewing many teams tackling various problems in the ML lifecycle we finally found the right team with the right vision and were fortunate enough to lead Qwak’s Seed round.
I got to know Lior and Yuval at AWS. The two were among the first Amazon hires in Israel, Yuval joining after a tenure as the CTO of IDF IT unit (Mamram) and Lior after spending time at IronSource, one of Israel’s largest and most advanced Internet Unicorns. By the time I joined, Yuval was constantly busy serving customers across EMEA as the dedicated ML-wiz that you call when things start to break. When they told me they were working on something new with Alon, who served together with Yuval in the IDF and most recently was Payoneer’s VP Data, I immediately wanted to hear more.
Another key component for us is Market Validation — mainly validation of the problem because the solution will change many times. But even more importantly, we sought validation of the team’s ability to identify and connect with prospective customers’ pains, and on the other end, for the prospective customers’ willingness to entrust the team with building a solution that they will buy. We didn’t need to make too many calls to reach a conclusion. All of our calls concluded with the VP we were talking to asking when they could start using the product. Another vote of confidence came from Ran, who was the Data and ML lead at Wix. Experiencing first-hand the problems described by Qwak, and hearing and sharing the same vision on how to solve them, Ran joined Qwak as a co-founder shortly after the introductory call.
Qwak’s vision is big. Eventually, they want to untangle the ties and dependencies between data scientists and ML/ Data engineers, bringing the agility of SW development to managing ML in production. To execute that vision, they’ve built a comprehensive product addressing multiple stakeholders’ needs, within a unified platform. It smoothly integrates with the common tools that most organizations use today. Onboarding a model onto the platform only requires a single line of code. Whether you are a data leader, ML engineer, or product team member at a company that explores or implements AI/ML in its products, I urge you to schedule a demo.
We’re in the very early innings of the ML revolution. At StageOne, we believe that it will touch almost every aspect of our lives and have been investing in horizontal and vertical startups in the space accordingly. The companies building ML-powered products and services are eager to find solutions to help them scale and build their offerings well. Qwak is up for the task, having been built by the right team at the right time.
On a personal note, Qwak also marks my first investment as I return to the investor seat. We’re thrilled to join Alon, Yuval, Lior and Ran in this exciting journey as partners. We’ll be working closely with our co-investors from Amiti and prominent Angel investors who joined us in this Seed round.
