Yugen.ai starts ML work with the business problem and a short-term goal, then chooses the smallest experiment that can show value.
2
System design documents help data scientists, ML engineers, and analysts agree on business context, architecture, measures, and trade-offs before implementation.
3
A silent data and code error distorted rankings for more than a week, which led Yugen.ai to invest more in tests and feature-distribution checks.
Summary
Soumanta Das describes how Yugen.ai grew from two people starting during the early months of the pandemic to a team working on ranking, recommendations, replenishment, and fraud detection. His central operating principle is to connect ML work to a concrete business goal, such as revenue or user return rates, and to move promising ideas into production quickly. He divides companies into zero-to-one and one-to-ten stages. Early teams need fast time to value and fast experimentation. Growing teams need those qualities plus engineering practices, testing, monitoring, and shared processes. Yugen.ai uses system design documents to bring people from different backgrounds onto the same page before coding. Das also explains how their infrastructure evolved from Lambda and simple dashboards to pull-request deployments, canary releases, SageMaker, Spark, and online features in Redis. A production bug caused missing values to become zeros and damaged rankings, exposing gaps in their tests and data checks.
Yugen.ai grew from consulting work into a full-stack ML services company
Before Yugen.ai, Soumanta Das worked mainly in data science consulting, where projects often ended with a presentation or an Excel file using model predictions. A product startup then introduced him to backend services and software engineering. He saw the gap between data science and software engineering shrinking quickly and used that as an early reason to start Yugen.ai around January or February 2020. The first customer arrived at the end of March. The company began with two people and had grown to eight by the time of the conversation, working on personalized rankings, product recommendations, and other full-stack ML systems.
The first production deployment made the steep learning curve worthwhile
Das had never deployed a model while working in ML consulting, so Yugen.ai's first customer forced him to learn deployment quickly. The team promised to show impact within three months, and a client suggestion pushed them to try deploying something in less than three weeks. Das learned about AWS Lambda, built pipelines and APIs, and stayed up late coding. Sending the first request to production and seeing it work gave him strong personal satisfaction. Since then, the team has reviewed impact regularly, including the scale of recommendations served and how many people use them.
Early ML teams should optimize for fast value and fast experiments
Das divides companies into stages from zero to one, one to ten, and larger organizations. For zero-to-one teams, he prioritizes very fast time to value and the ability to experiment quickly. A small product may change its features or expand into new countries, so the team will not have stable answers at the beginning. For one-to-ten companies, fast experimentation still matters, alongside a strong engineering culture and a proper MLOps process. Testing and monitoring became especially important at Yugen.ai after the team initially underinvested in them.
ML work should begin with the business problem and the immediate goal
Das says ML is a method for solving a business problem, so teams should first define what the business needs to achieve. Yugen.ai sets one-month or three-month goals with stakeholders from product, marketing, and engineering. The goal might be revenue for one use case or user return rates for another. Those goals guide the bets that enter each sprint. The company keeps a longer-term vision, but it avoids spending one or two months building a model and checking only offline accuracy before production. If an experiment shows promise within a few weeks, the team tries to move it forward.
System design documents connect people with different technical backgrounds
As Yugen.ai hired people from software engineering, data science, and business analysis, Das saw different assumptions about production work, code quality, speed, and maintainability. The team began most exploration tasks and new features with a system design document. It records the business problem, what the finished feature should do, how success will be measured, and a small architecture diagram. Team members review the document together before implementation. This gives pull requests a shared context and reduces the need to reconstruct decisions from Slack messages and emails. The discussions also help data scientists and ML engineers understand each other's trade-offs.
Code reviews helped data scientists reuse production patterns
Das gives an example from personalized ad ranking. Data scientists sometimes built new model variants from scratch in a notebook, writing custom functions and using loops to reach an iteration quickly. During GitHub pull-request reviews, ML engineers showed them existing helper functions and vectorized implementations already used in production. One change reduced a proposed 400 or 500 lines of code to a much smaller amount by reusing five helper functions. The data scientists adopted these patterns after seeing that they reduced work and made operations faster. ML engineers also began proposing simple experiments because they understood the data, business, and existing code.
Minimum Achievable Goals turn broad plans into short bets
Yugen.ai's Minimum Achievable Goals are similar to an MVP, with input from several stakeholders because the company works in services. The team decides what matters for the next month or three months, then chooses among possible ways to affect that outcome. A revenue goal may lead to several models, experiments, or small product changes. Das wants the team to identify the larger bets early and make them short goals rather than waiting for a six-month target. He also agrees that teams should avoid ML when a simpler rule-based solution is enough.
A simple model produced the first measurable improvement
For a personalized ranking system, Yugen.ai started with a rule-based algorithm already used by the customer. Das built a simple linear regression model in three days after spending a day understanding the available data. The team did not try to build an advanced model with limited data and few users. That model reached production in about two weeks and produced roughly a 0.8 to 1 percent increase in one customer KPI. Later work added user personalization and personalization across countries, making the system much more complex, but the first useful step was deliberately small.
Scaling exposed both data drift and deployment pressure
As new countries, user groups, and promotions arrived, Yugen.ai saw data drift because the incoming users differed from the data used for earlier models. The team created automated processes to start EC2 environments, train models in parallel, and give several data scientists room to work. Deployments also became more demanding, with three or four models going live every two weeks. The team moved from a basic Lambda setup to a Flask system on EC2 when usage reached around half a million users and about a million visits. It reached a larger scale after testing and stress testing the new design.
"ML at the end of the day is a very important method or a very important way of solving a particular business problem."Soumanta Das12:27
Who should watch
You are building ML systems for customers and need a way to choose short, measurable goals before committing to a large build.
Your data scientists and software engineers review each other's work poorly because they have different ideas about production, maintainability, and speed.
Your models show changing performance and you need practical examples of deployment growth, data drift, testing gaps, and feature checks.
