We did a ton of manual unsexy work in the early days. Like we tried hiring an initial data labeling team and they weren't accurate enough. So I would spend a lot of my time just labeling boxes on documents. If you stacked all the pages that Reducto processed, it would actually be something like 10 times the height of Mount Everest back when we were still fully unautomated for Stripe billing and setup. Like I would manually set up every single subscription.

And those things, even though they were repetitive, even though they were maybe boring in terms of the work that you're doing, were okay because the thing that I cared about is not "am I doing the most glamorous work." It was more so like: is the company moving forward? You're lucky to be able to do that because that means you're signing up a new customer. Like it is a privilege that you get to do that.

Hi, my name is Adit Abraham. I'm the co-founder and CEO of Reducto. Reducto is a platform that helps AI teams parse, extract, and edit any sort of complex unstructured data for all sorts of language model use cases. Reducto has grown incredibly quickly. We've raised 108 million in total funding from incredible investors like Andreessen Horowitz, Benchmark, and First Round.

Today, Reducto powers ingestion for some of the best companies in the world. That includes really large Fortune 10 enterprises, but also newer leading AI companies like Harvey, Rogo, and Meror. To date, we've processed more than a billion pages for them and are continuing to grow every single week.

Ever since I was young, I always used to have side hobbies. In high school, I saw an article that said something like the creator of Flappy Bird is making $50,000 a day on ad revenue. So, me and my best friend in high school just immediately had this gut reaction of, you know, forget school, forget all of that, we're just going to make apps and that's going to be our future. At some point, we even discussed not going to college.

Things didn't work out that way. We tried a few things but did end up going to college and pursuing a longer career from there. But I think it was a really nice inspiration that kind of showed how going off the beaten path can lead to outlier outcomes for folks. Even though we don't work on game development today, I do think there's something very valuable about seeing individual effort that sometimes just starts as side projects spiral into something much, much bigger.

That eventually led to me going to MIT, did my undergrad in computer science. I remember I was taking my first grad-level ML course. So it was a course on meta-learning, like teaching models to learn. And on the first day of the course, the professor introduces Ronic, who at this point is a freshman. Like it's his first week on campus probably. And he frames it as, "Hey everyone, meet Ronic, he's going to walk you through how to do the first p-sets."

So Ronic was a learning assistant for this course that was primarily PhDs. And that was crazy to me. Like it was this person that even though he had just come onto campus, a campus with really smart and exceptional people, he was already at sort of the top. And so we became really close from there. The first time Ronic suggested that we could work on something together, that was an immediate yes for me. Like I didn't think twice about leaving my job or anything like that. He was just somebody that I admired enough for it to just be a no-brainer.

So in the course of the company, before the YC batch, we actually gave up on revenue multiple times. We tested different ideas, got to a point where people were willing to pay for it, but decided that the urgency with which they were willing to pay for it, or the need to which they wanted the product, wasn't high enough for us to want it. And so just to give you a sense of what this looked like tangibly when we were selling Remember All, we would constantly find, you know, at best people were willing to pay $50 a month or maybe $100 a month.

So Remember All as a product was at that time the first long-term memory API for language models to remember things that you'd mentioned in the past. We would store context that was important and retrieve it when it was relevant. As you would talk about things like implementation times, it was never the number one thing that they needed to focus on. And this was kind of one of those things that was nice to have.

In comparison, one of the things that we built for Remember All is people would say, "Hey, you're managing the user's chat history. Can you also manage the files that they upload?" Almost like a managed RAG service. And we saw that as, you know, a simple feature that we would add with off-the-shelf tools. When we would demo Remember All, we would find that people would get really excited about the fact that we were managing the files that they uploaded.

We had put so much time into making that file management better. We started training our own models. We did a technical blog in YC's forum talking through how we segment documents. That wasn't packaged as, you know, a clean demo or anything like that. It was a really simple Streamlit app. It was: you would upload a document and we would draw boxes on that document.

And surprisingly here it was almost like they were pulling us. They immediately started replying with, "Hey, these are better results than what I'm seeing from my existing vendor. Is this a hosted API? Do you have a Stripe link? Like can I purchase this? Can I start using this?" It's almost like a slap in the face in terms of how much the market wants the product. And so when we were considering whether or not we should have high conviction in the space or not, that was the biggest thing that concerned us. We knew that in a year, two years, three years, in some span of time, long-term memory would need to exist. But what we wanted was to solve the problems that people needed solved immediately, to solve the things that they were actively looking for a solution for. And we decided that Remember All was not that.

There are quite a few different ways that somebody can demonstrate how much your product means to them. It's not just the money, it's the time that they're willing to put into making the product great together. We've put a ton of time into, you know, aggregating data. It's a big part of what we do and it's a big part of why we've been able to train state-of-the-art models, but production data is different. We work with really intensive financial, healthcare, insurance use cases that you're never going to find on the internet.

And so, really quickly, we started having customers that, you know, had tried public documents and saw exceptional performance, but they would come to us with the most esoteric examples imaginable. Like we've seen really hard cases where a doctor annotated things and you know they just put things at the bottom of the page and you were supposed to understand that it related to the thing at the top. We see really intensive financial tables with thousands of rows of data, everything along those lines.

The nice thing is our customers want us to solve those and so we've always had this almost design partner-like relationship where they will come to us with that sort of feedback and we will iterate day after day after day to make the models better. And when you fix that feedback, they end up telling you whether or not that worked or it didn't. And you iterate by the end of that first week, you've already made a ton of progress with them. And that is really meaningful in that they care to make sure that your product is great. Like you're on the same team, you want to make the product better together because the work that we do directly helps them too.

And so from the early days even to now, we would set up individual Slack channels with all of our customers. I have their phone numbers, like we would call directly and if they ran into issues they would just call us. Like they would tell us, "Hey, like this isn't working, we need this for a big customer," and we would work late into the nights to make sure that it was working for them because we don't take it lightly that people decided to trust us from an early stage.

They have many reasons to not. They have all the reasons in the world to choose an established company that you know has been around for a decade. And part of the way to pay back the trust that they've given us is to be there for them on an individual level. So even today, you know, if a company has an issue, they can just ping Ronic or me directly. Part of what they're getting with Reducto is us as their ingestion team.

There's a world where we just relied on marketing. Hey, it's the best product. Hey, it's state-of-the-art. All those things. But there are many companies that can say that. And on the flip side, the other thing that we could do is actually put the product in front of people even if it wasn't a perfect platform to let them see on their hardest documents that it works to prove what you're saying is true. And that translated to the company growing really quickly.

At least in our case, being public in that way just meant that companies that otherwise probably would have ignored Reducto became really interested. Like when we were a two-person company, a trillion dollar enterprise decided to book a demo. And the reason why they booked a demo is because we had that public playground where they uploaded hard documents that they'd seen fail on every other vendor. And once they saw that work, that justified reaching out.

And if we hadn't done that, if we were this two-person company of, you know, 20-some year olds, I find it hard to imagine that they would even be interested in engaging with us. If we'd been shy about what we were building, we probably would have never gotten on the phone with them. When we say that we are the most accurate product in the market, we really mean it. Here are some examples, but if you want to see further, like you can test that for yourself.

I had known quite a few investors from just the course of building the company. And I think a lot of early stage founders think in terms of firm brand. Like they only think of tier one VCs as the actual firm which you know many of these firms have been around for decades and you know have their own reputation from them. But at the end of the day the thing that matters most is ideally whoever you're raising money from, like that individual partner is somebody that you're going to be partnering with for the next 10 years. They're going to be there in all of your great successes... but they'll also be there for the bad moments of the company. They'll be there when you have to, you know, let an employee go. They'll be there when you lose a contract. They'll be there when you have a big, I don't know, media incident, whatever could happen in the lifetime of the company.

But it's really important to see how their interactions changed when things weren't going well. I remember there was a moment where Liz, our seed investor, actually basically never takes time off. If I text her at 10:00 p.m., she's replying at 10:05. She's getting on the phone like doing whatever. And one of the only moments where she was taking time for herself, I think she was at a Broadway show with her husband tragically. Like I wish we hadn't done this. But we had an OpenAI outage at the same time.

And so Ronic was like frantically, you know, messaging her like, "Hey, like what do we do? Our keys aren't working. Customers are upset." And even though it was one of the only times that she had to herself, she just immediately stepped out. She started calling people in her network and very quickly actually had the chief product officer at the company on the phone trying to help us with our issue and we were not an important enough customer for them to be doing that. These partners are committed to helping the company succeed and that is really important. So if you're an early stage founder thinking about who to raise from, take the time to actually understand what that is going to look like because it's one of the most important decisions you'll have to make.

I think with every moment that is really exciting in a company, the thing that isn't discussed in interviews is what it took to get to that moment. Um, like when we were landing our first really big enterprise contract, it was an on-prem deployment and we had never done an on-prem deployment before. You know, we didn't have infrastructure engineers on team, we weren't this large org that could divvy up responsibilities.

We would wake up, we would immediately go to the office and we would be in the office until we were too exhausted to continue working. We would sleep for at most a few hours and then we would go back and we would try again and again and again. People diving in and doing anything at the company. There's no sort of notion of "hey if you're an engineer you don't need to do customer support." There's no notion of like "hey you know if you're an ops person you don't need to label data for the ML team" because everybody just wants to see the company succeed.

Um, and the company succeeds when all of these things work, when the product works, when customers are happy. And people don't think of their job in terms of whatever their role title is. They think of it in the capacity that they can help the company move forward. And so what I see Reducto as, it's not really just parsing. It's what does it mean to have this layer that connects human data to this new level of intelligence that applies across all of that data.

Um, we're seeing products built with Reducto today that don't just read the documents, they actually create net new documents for their end customers. Like they do end-to-end work with agentic workflows. In the future, most AI products will be some component of intelligence. That is what the foundation model companies provide, but it will be some components of context as well. And we want Reducto to be the best way that you interact with that context, like a building block that you aggregate together and apply it to a specific use case.