When people hear that we clean and annotate the data used to train AI models, they picture a technology company. A room full of engineers, a platform, a stack. Recently someone on my own team asked me the question plainly. Now that the AI data work has grown, are we becoming a tech company?
My answer was probably not the one they were hoping for. No, we are not, and at this stage we are not trying to be. I want to explain why, because the honest version of that answer tells you more about how AI data actually gets delivered than any pitch about tooling would.
The assumption every buyer walks in with
The instinct to see this as a tech problem is understandable. The output is data that feeds a model, so people assume the hard part must be software. It is a reasonable guess, and it is mostly wrong about where the difficulty sits.
The software is the visible part, the part that is easy to point at. The difficulty lives somewhere less obvious. It lives in finding the right people who can actually produce the right data, in running the work, in holding quality and timelines across a large group, and in delivering something clean at the end. None of that is a coding problem. It is a coordination problem.
What actually consumes an AI data project
If I describe the AI data vertical in the plainest terms I can, it is project management. We take up a project, we execute it, and we deliver it to the client. That sentence sounds modest, but everything hard about the business is packed inside it.
We have always thought of ourselves as a people's company. We bring the right people to a problem and we take responsibility for what they produce. Entering AI data did not change that. It simply pointed the same capability at a new kind of output. The work that consumes a project is the human work: sourcing contributors who can do the task well, keeping them available and on track, and making sure that what reaches the client is right. The technology sits around that work. It does not replace it.
The AI data work is not really technical. It is project management. We take up the project, we execute it, and we deliver it.
Where automation fits, and where it does not
This is not a case against technology. We use a great deal of automation, and it is genuinely useful. But it comes into the course of doing the work. It speeds up parts of execution and takes friction out of delivery. What it does not do is remove the need for the right people or the judgment that decides whether data is actually good.
Could we lean far enough into that automation, a few years from now, to reasonably call ourselves an automation company? Maybe. I am not certain, and I would rather say so than pretend I have a grand plan I do not have. The honest position today is simple. Automation serves the delivery. The delivery does not exist to show off the automation.
Why we are not chasing a product
It would be easy to dress all of this up as a tech company and go chasing a big platform. That is exactly the kind of ambition that is easy to fail at, and I have watched enough companies fail at it to be wary. For every one that built something large, many more tried and quietly died, and their founders went back to jobs.
So our goal is the opposite of aspirational. It is to go deeper into what we already do, across recruitment, e-learning and AI data, and to earn real revenue from that depth. If a product or a platform is ever worth building, it will come out of that revenue and that depth, not out of a pitch. For the next couple of years there is no product focus at all. Build the roots first. If they earn something worth building, build it then.
What this means when you choose a partner
There is a practical takeaway here for anyone buying this kind of work. A tooling-first vendor tends to sell you their platform, and the responsibility for the outcome quietly stays with you. A delivery-first partner takes responsibility for the outcome itself, the clean and correct data in your hands, and uses whatever people and tools the job actually needs to get there.
So when you evaluate partners, look past the interface. Ask who owns the delivery, and who is accountable when the data simply has to be right. In my experience that question separates the companies that will carry your project from the ones that will hand you a login and wish you luck. The software is never the thing that decides whether your data is good. The people and the ownership behind it are.
A tooling-led vendor sells access to a platform. A delivery-led partner sells a clean, finished outcome.
With tooling, the responsibility for quality stays with you. With delivery, the partner is accountable for it.
Ask who owns the result when the data has to be right, not who has the most features.
Judge a partner by the people and the ownership behind the work, not by the interface in front of it.
About the author
Amitt Agrawaal is the founder of ConsultBae, a bootstrapped company built across recruitment, e-learning and AI data. He is a believer in growing deep rather than fast, and in taking responsibility for delivery rather than selling tools.
You are not buying software. You are buying data that has to be right.
If you need clean, annotated training data delivered end to end, tell us the outcome you need, and we will own getting you there.
Talk to our AI data team
