So the next one in the series of me and my entrepreneurial dream.
I joined Captain Fresh because the problem space was around fishermen, aquaculture, satellite imageries, and building a product around it. I was hired as a Data Scientist 2 position, but I ended up doing almost everything possible—building machine learning models, especially computer vision based deep learning models on top of satellite imageries to understand biomass availability and harvest readiness of aquaculture ponds. I was also working on oceanographic data to understand migration patterns of different fish species.
The Projects That Shaped My Understanding
Along with these, there was another attempt we prototyped: developing a Shrimp Atlas. It was about understanding which places have demand for exporting shrimp, where the supply is concentrated, seasonality-based availability, and many other factors. I conceptualized it as an S&P 500 kind of indexing of different zones based on exportability, combining data points from satellite imageries and market data. It was essentially market intelligence around the shrimp and seafood market.
Initially, I started with these computer vision projects, but it wasn't just about building that particular model. It was also about building the consumption layer—how farmers can use it, how it can be part of a mobile app or web app. So we went into deployment, scaling, and building more insights on top of the model. For example, historic trends, different utilities that customers might want—like geofencing specific farmland and getting insights from that.
We were doing a lot of user interviews to understand gaps in the product—from the procurement team side, from business people, from farmers. We went to Ongole, Nellore side areas to see how actual operations happen at the fields and how our products can help them.
The Three Aspects of the Product
The product solved two or three aspects. One was utilizing remote sensing. Another was utilizing in situ observations—combining them to provide more data-driven information. Since we were capturing in situ observations, it became a kind of journal or diary for field operators. They could log water conditions daily, and with that, we could bring in different metrics to assess the quality and liveliness of aquaculture ponds.
This was a very good use case in a very niche industry. It gave me everything—building models, user interviews, deploying things, scaling them up, and understanding what customers actually want.
Along with that, there were other components as part of the bigger product lines—the oceanographic work that could help fishermen understand potential fishing zones and fish migration patterns. It gave me a clear direction: there are problems where you can build products with machine learning or data science as the core component. Not just simple utilities or heavy software, but data-centric products.
Doing Everything: The Full Stack Experience
At that time, I was biased towards doing everything myself, and I was actually doing it. Building the backend, building the frontend for the web application, developing models, deploying them. Along with that, doing user interviews, understanding what users might want, working on proposals, pitch decks, mockups.
Me and Parag were even working on financial planning—how much it would need to operate a company for one whole year. We calculated it elaborately: around 9 crore to run a team of 20 people consisting of different engineers—data science, machine learning, frontend, backend, DevOps, and some research engineers on the aquaculture and satellite imagery side.
We even had a plan of building and launching our own satellites. At that time, we were studying companies like GalaxEye, a Bangalore startup launching small satellites and providing satellite remote sensing products like flood monitoring and asset monitoring. We were trying to validate different data sources that might help us.
We had a working prototype. It was actually used by procurement teams. We were doing backtesting to see how it was helping people. We even presented this idea at the Ocean Society of India conference in Hyderabad under the blue economy theme.
The Product-Market Fit Challenge
But there was a lack of buy-in from the business side. The commoditizing part was quite scattered. We built this product, but we couldn't just sell it as a standalone data product that any fisherman or farmer can use by paying a subscription. There had to be some business or further economy linked to it.
The product-market fit was loosely coupled. Some companies tried similar things but tied the data product with a marketplace where farmers could buy fertilizers and other inputs. That approach becomes asset-heavy and distributor-heavy.
So it was decided to keep it as a sub-product that helps other business processes. It couldn't be a standalone product or standalone business because it didn't have that tightly coupled product-market fit with a clear monetization path. It's a good use case—people can benefit from it—but how do you charge for it? How do you make people stick with it? We were betting against traditional knowledge that farmers already have. There were a lot of gaps to fill.
Learning How Products Really Get Built
During that time, I worked with different sets of people—very good backend engineers working on Golang, DevOps engineers scaling ERP products. I got a real understanding of how products are built and how product supply chains actually work.
There were product managers and associate product managers who meticulously came up with features and figured out how to serve customers. In Mu Sigma, it was all projects and engagements—no effort towards building one product for multiple clients. But here, it was about building one neat product that serves a similar segment of customers. That involves a lot of engineering effort.
I closely observed how people build such things, learned from it, and also worked on backend development for the ML and data science models. There was one person who joined from IIM Ranchi who was conceptualizing a new product line for seafood distributors and retailers.
It was good collaboration—one company, different products: products for farmers, products for distributors, products for factories. In every conversation, I was discussing how data can help them, how machine learning can help in forecasting, optimization, computer vision applications.
I could see my skills from Mu Sigma transferring here. The way of understanding customer problems and thinking through solutions—that helped while creating product mockups and proposals.
A Wholesome Experience
It was a wholesome experience. Learning user interface design, learning remote sensing, backend development. That was the first time I was fully working on Docker and Kubernetes for scaling models. Working with product managers from different IIMs and backgrounds.
I remember one product manager, Suresh, who had worked with crypto companies, consumer products, baby care, healthcare companies. Those conversations really helped me understand what to look at when evaluating different products.
The product was called TraceLit because it was about building traceability pipelines for shrimps and fishes. The idea was that with traceability, there's premium pricing that can be set for these products.
Going Deep: Research and Experimentation
As I mentioned, there was lack of product-market fit. That's when I started exploring more around customer obsession—how it gets built. I read "Hooked," the book about how e-commerce and social media products gain customer stickiness and retention. I started observing a lot of startup stories, other product companies, different VCs. This all started happening around 2022 and early 2023, developing a good understanding of products and how people position them.
We went till the level of productionization and financial planning, with the mindset that we need research as a backup—teams that keep running and improving. We were even working with an IP company to get patents.
We explored as much as possible. We put efforts into developing our own datasets—annotating a lot of data, collecting data from different places using data collection tools from farmers.
On the deep learning research side, we went ahead and fine-tuned architectures for our satellite imagery models. Not just using UNet or segmentation transformers, but fine-tuning with our data. We tried different architectural aspects—like bringing in cloud removal from satellite imagery to increase coverage.
We were also doing initial experiments on causal inference with in situ experiments—comparing multiple ponds to see how different fertilizers or climatic conditions impact outcomes. That gave me some idea about how people really do field experiments.
The Cost Reality of ML Products
When building something for business, some early experiments may not gain interest from others. For field experiments or developing custom models that need more GPU and compute—in our product team, our model training expenses were much more than all other product deployment costs combined.
A simple number I still remember: in a month, we were burning around $8,000 for model training experiments and hosting on AWS, versus around $1,000 for all the mobile application backend hosting for other product lines.
We were doing a lot of training, and the scale was high. Not just a few images—hectares of satellite imageries to run inference on. Training was happening on A5000 or A6000 level. We even moved to A100 level training, which was very costly back then. Now GPU costs have reduced a bit.
On the larger scope, sometimes smaller steps miss getting encouragement or focus. We have to see the entire business and direction rather than some early experiments.
The Shift in Interest
That's where I saw a change in interest. I was getting more focused on tuning myself towards machine learning and LLM research rather than having other shared responsibilities like product building, venture building, getting more business deals, and managing teams.
At that time, around three and a half years of experience, I had a very versatile background—worked on a lot of machine learning problems, different clients, different problem spaces, backend, frontend, deployment. I would say that was the peak or a very good start of my career, working 12-15 hours a day sometimes.
Then I felt my entrepreneurial curiosity starting to decrease, while my curiosity and ambitions towards developing myself in higher-level machine learning—LLM research, frontier AI—started increasing. I was curious about where I could get started with that.
Joining Informatica
That's how I joined Informatica. They were building custom LLMs, working on different AI experiments for specific domains. I was curious because I felt I needed to build my niche specialty, the depth I was looking for.
But even as my entrepreneurial curiosity reduced, I got to work with one company—a stealth mode startup where I was helping them as AI Lead, right from setting up the team, building models, and giving shape to the product itself.
They were in services for insurance and medical document synthesis and had a dream of building a product and launching it as a startup. I thought, maybe I can help them and see how far we can take it. It was also about testing myself and learning how good I am at this.
For this company, the product-market fit was much clearer. Build a machine learning model, build utilities around it—different data access layers, decision-making layers around these models. This was happening in 2024, and the demand for LLMs and vision language models was high. Pure AI-native products started developing in 2024.
It was the right time. They needed my help, and I started working with them. It showed me how I'm able to grow further, able to take control in building such things.
What Came Next
In the next part, I'll share my journey with Informatica and the stealth company, where I explored building very good machine learning solutions and models, along with utilities and products around them.
At Informatica, it was about building a machine learning product for engineers. Informatica had around 2,000-3,000 customer support engineers. How do you build a troubleshooting product—essentially an observability product for them? There are companies like Observe, Datadog, Support Logic. My role was building the observability plus AI combination product for engineers so they can reduce their time searching for solutions.
Parallelly, at the stealth startup, I was helping build custom AI models—small language models and small vision language models for medical document synthesis. I was also helping some friends build their narratives and products.
Let's see what I learned in Part 3.
To be continued.