Datalab grew to seven-figure ARR and trained document models with a team of four by keeping roles broad and handoffs rare.
2
Small teams work when members are senior generalists who talk to customers, build across the stack, and use AI and simple internal tools for routine work.
3
Productivity should scale through better people, more compute, and AI tools rather than automatically through higher headcount.
Summary
Vikas Paruchuri explains how Datalab grew revenue, open-source adoption, and model capability with a very small team. His argument comes from seeing productivity and happiness rise after layoffs at his previous company, Dataquest. He attributes that change to fewer specialist silos, fewer meetings, less management overhead, and sharper priorities. At Datalab, generalists handle customer conversations, research, training, inference, and product integration. AI helps with lower-level work such as data pipeline code and API integration. Paruchuri recommends simple technology, reusable components, readable code, high trust, and in-person work for teams that need fast feedback. He is honest that the model may not work forever and that it requires a high hiring bar. Datalab tries to fill product edges with models rather than large forward-deployed engineering teams. Hiring focuses on public work, open source, a paid project, and interactions that reveal how candidates think and work with others.
Reducing headcount made Paruchuri's previous company more productive
At Dataquest, Paruchuri scaled the company to 30 people and $4 million in bootstrapped ARR, then went through layoffs from 30 to 15 and from 15 to 7. A few months after each reduction, productivity and happiness increased. He connects this to specialist roles that could not move across the company, remote-work processes, meeting overload, and senior employees spending time managing junior staff. In one example, a three-person team became more productive after being reduced to one person because the senior employee regained time to do the work.
A small company should keep fewer than 15 generalists
Paruchuri describes Jeremy Howard's approach at Answer AI as hiring fewer than 15 generalists who can understand the whole company and work across its stack. AI and internal tools fill in the edges. He points to FastHTML and MonsterUI as building-block libraries for creating internal tools, and he recommends simple technology instead of infrastructure that a small team does not need. This model requires people who can both talk to customers and build, along with high trust and a shared focus on customers.
Generalists shorten the path from customer need to shipped model
Paruchuri uses Surya OCR 3 as an example. He and Datalab research engineer Darun handled customer discovery, paper reading, architecture decisions, prototyping, training, data cleaning, dataset construction, inference code, repository integration, and product integration. In a larger company, those tasks would likely be split among several teams. Each handoff loses context, so customer feedback can take months to affect training. A generalist team keeps the context together and can use AI for lower-level tasks such as data pipeline code and API integration.
Senior means ownership and maturity, not a number of years
For Paruchuri, a senior generalist sees a problem and says, "I'm going to figure out how to solve this." The person must care enough to iterate with the customer and finish the work. He also warns engineers against overcomplicating ordinary problems with infrastructure and suggests choosing the simplest workable approach, such as a shell script on one machine. His version of seniority is practical ownership, customer attention, and the ability to move without constant management.
Simple architecture leaves more room for useful work
Datalab reuses components between its on-premise and API deployments and keeps its technology stack small. The company does not use React or elaborate front-end frameworks. It uses server-rendered HTML with HTMX and Alpine. Paruchuri says clean, modular, well-documented code is easier for AI to extend, citing the rearchitecture of the Marker repository. He also wants few moving parts, little bureaucracy, continuous discussion, and people who can work quickly without needing much management.
Models can absorb customer-specific document behavior
Document intelligence customers often want documents parsed in slightly different ways. Paruchuri compares this with older OCR companies that sent engineers to customer sites to iterate until the output was acceptable. Datalab wants to train models that can loop over customer outputs until they reach the desired state. That could reduce the need for a large forward-deployed engineering function. He admits the approach is still early and may fail as the company grows, so the company must choose carefully which product edges to solve with models.
Small teams depend on broad roles and low political behavior
Datalab has three core roles with substantial overlap. Everyone talks to customers and contributes to the product, while research engineering and full-stack engineering overlap. Go-to-market combines sales, marketing, and support into a broader role. Paruchuri says politics can damage a small team, so he looks for people with low ego who will push their ideas without harming the company. He also favors top-of-market pay, meaningful end-to-end work, patience in hiring, and candidates who demonstrate that they will ship rather than only discuss shipping.
Productivity can grow through people, compute, and AI tools
As a company scales, Paruchuri wants productivity to rise without assuming that headcount must rise at the same rate. He suggests raising salary bands so the company hires more experienced people into the same roles. Compute also changes output: one researcher with access to eight GPUs is less productive than one with access to 64 GPUs. AI tools can multiply productivity by handling some of the surrounding work. In the question period, he adds that smaller teams also force ruthless prioritization because there is too much work to create unnecessary features.
Hiring tests real collaboration before making an offer
Datalab's hiring process has three stages. It starts with a short peer-style conversation around a real challenge. If that goes well, the candidate and team build a project together. The project usually takes about 10 hours, is paid at $1,000, and gives both sides a practical way to assess fit. The final step is a culture-fit conversation focused on how the group interacts as people. Paruchuri says about 40% of people interviewed have eventually been hired.
"The worst hires I've personally made have all been when I thought I had to fill a role very quickly."12:21
Who should watch
You are building an AI startup and are deciding whether a new hire should be a specialist or a broad owner.
Your team is losing time to handoffs, meetings, or management work and you want concrete ways to reduce that overhead.
You are hiring engineers who need to move from customer feedback to shipped product or model changes without waiting on several teams.