Small AI Teams with Huge Impact — Vik Paruchuri, Datalab

How can a team train models, maintain open-source repositories and build a business without immediately hiring separate teams for each? Vikas Paruchuri opens with Datalab’s results: he reports 40K GitHub stars, seven-figure annual recurring revenue and models he describes as state of the art, achieved with three people. Over the preceding year, he had trained models and built repositories around Marker and Surya, left his AI research job, founded Datalab and raised a seed round.

Those results describe an earlier team size. At the recording, Datalab had four people, and Paruchuri reported fivefold revenue growth since January, when the company made its first hire. The newest colleague, Faraz, was not yet in the team photograph. Customers included major AI labs, universities, Fortune 500 companies and AI startups. Gamma was both a customer and the tool he used to make the presentation.

Headcount does not equal productivity. Raising money, hiring people and building more can look like a natural sequence, but Paruchuri’s previous company made him question the connection. Dataquest, a bootstrapped online education business, reached 30 people and $4 million ARR during COVID. When online education contracted afterward, it went through layoffs from 30 to 15 people, then from 15 to seven. He acknowledges how awful those reductions were for the people affected.

Paruchuri reports that productivity and happiness increased a couple of months after each layoff, eventually exceeding their levels before the reductions. The observation prompted a question: what had the larger organization been spending its capacity on?

He offers four explanations from that experience:

• Specialization: people hired into narrow functions could not readily move to the company’s most pressing problems.
• Synchronization: a remote organization required deliberate process and frequent coordination to keep people aligned.
• Meetings: middle management added more scheduled coordination, leaving less time to make things.
• Senior attention: experienced people spent substantial time managing less experienced colleagues instead of directly solving problems.

In one example, he says a team became more productive after shrinking from three people to one because the remaining senior person could concentrate on the work.

An early company often has a period when everyone understands the product, the business model and the work that matters. Paruchuri points to Google Search and Microsoft Windows as examples of defining products around which companies formed. Expansion then fills out the surrounding functions: enterprise sales, marketing and engineering roles with increasingly narrow scopes. His deliberately extreme illustration is a friend at Amazon who, he says, spent two years working on a shopping-cart button. The concern is the accumulated bureaucracy, synchronization and uncertainty about priorities. Could the initial period of shared context last longer?

Working with Jeremy Howard at Answer.AI gave him a possible organizational design: fewer than 15 generalists who understand the stack and the company, with AI and internal tools covering the surrounding work. He connects Howard’s investment in FastHTML and MonsterUI to this approach: reusable building blocks make it easier for a small group to build the other tools it needs. The infrastructure should stay equally straightforward; a three-person company need not start with a Kubernetes cluster.

That design sets a demanding cultural requirement. Engineers must talk to customers, and go-to-market people must build. People need both the ability and the desire to understand work outside their primary specialty. High trust makes that overlap workable: colleagues are building something together, rather than protecting territory or optimizing for personal advancement. Shared customer focus supplies the basis for deciding what to do next.

The concrete technical example is Surya OCR 3, which had shipped but had not yet been announced at the time of the talk. Paruchuri describes a 500-million-parameter model supporting 90 languages, with 99% accuracy on Datalab’s challenging internal benchmarks, including math. The talk does not specify the accuracy calculation or dataset composition; these are historical internal results, and the current repository describes a later model and different evaluations.

The model produced character-level bounding boxes—a capability Paruchuri described as distinctive—and used PDF text as grounding at the line level. Delivering it required him and research engineer Tarun to own the development process from beginning to end:

1. Talk to customers and identify what they needed.
2. Read papers, select an architecture and prototype it.
3. Build the data pipeline library and datasets, clean the data and train the model.
4. Write inference code, connect it to the repositories and integrate it into customer-facing products.

His joke about training captures where much of the effort went: you hope the work will be mostly architecture, but it becomes mostly data cleaning.

Paruchuri estimates that a larger company might divide this scope among four teams. Each handoff creates a translation problem: the people who heard the customer explain the need communicate it imperfectly to the builders, who communicate it imperfectly to the model trainers. Meetings consume time trying to reconstruct that context without fully recovering it. A customer conversation can consequently take months to influence training.

End-to-end ownership keeps the reason for a change attached to the work. The same people can connect customer needs to model decisions and product behavior, shortening the feedback cycle. AI helped make that breadth manageable by assisting with lower-level tasks, such as building the pipeline library and working out API integration. Paruchuri and Tarun retained the higher-level decisions across those areas. The organizational gain came from combining broad human ownership with assistance on implementation work.

Operationally, this starts with hiring senior generalists. Paruchuri uses seniority to mean maturity rather than years of experience: someone takes responsibility for figuring out a problem and cares enough to keep iterating with the customer. That includes resisting an engineer’s attraction to elaborate infrastructure. For a data-extraction problem, a Kubernetes cluster and multistage pipeline may be unnecessary when a shell script on one machine will do.

For example, a batch that only needs text from digital PDFs can begin with a shell loop around pdftotext, with that utility installed:

#!/usr/bin/env bash
set -euo pipefail

mkdir -p text
for pdf in documents/*.pdf; do
  [[ -f "$pdf" ]] || continue
  name="${pdf##*/}"
  pdftotext -layout "$pdf" "text/${name%.pdf}.txt"
done

This illustrates the one-machine approach, not Datalab’s OCR implementation: it extracts existing PDF text and does not recognize text in scanned page images. The useful starting question is whether the actual task requires distributed infrastructure.

Paruchuri recalls a Hadoop-versus-shell-script article in which a single 64-core machine could replace a cluster. The exact article and hardware detail are uncertain; the principle he draws from the recollection is to value simple solutions. He also favors working in person for a small team that needs to move quickly. He acknowledges remote work’s benefits, but in his experience the additional process needed to coordinate it slows continuous collaboration and tight feedback loops.

Datalab applies the same principle to its architecture. It reuses components between on-premises and API deployments instead of maintaining separate implementations of the same capabilities. Its frontend uses server-rendered HTML with light HTMX and Alpine, rather than React or an elaborate frontend framework. Paruchuri also says the team rearchitected marker into modular, well-documented code, making it easier for AI to contribute useful changes.

These choices reinforce one another. A small organization still has to maintain everything it creates, so complexity consumes the same scarce attention needed for customers and product work. Paruchuri extends the constraint to hiring: someone who needs extensive management may not fit this operating model.

Document intelligence introduces an obvious pressure to hire: every customer wants documents parsed slightly differently. Earlier OCR companies often addressed this by placing forward-deployed engineers at client sites, where they could repeatedly adjust the system until its output was acceptable. Paruchuri proposes a different route: train a model to loop over customer outputs until they reach the desired state. In that proposal, the model would absorb work otherwise assigned to a customer-specific engineering function. He presents this as a future direction, not an already demonstrated replacement.

The limits remain open. Paruchuri points to Gamma as another small team with meaningful ARR growth, then shifts the question from what a company can accept to what it can decline. Hiring engineers to work at every client site is a choice; so is solving the problem another way. The alternative might capture revenue less efficiently in the near term while better supporting the company’s long-term health. He explicitly does not know whether this organizational model can work forever. Preserving it requires deliberate choices about which complexity to take on.

Datalab organizes around three overlapping roles: research engineer, full-stack engineer and go-to-market. Paruchuri jokes that the awkward Venn diagram reflects an LLM’s difficulty drawing it, but the intended overlap is practical. Everyone talks to customers and builds product in some form. Research and full-stack engineering share substantial responsibilities, while go-to-market combines sales, marketing and support in a generalist role.

The overlap depends on low ego. People need enough confidence to advocate for ideas without fighting for them at the expense of colleagues, customers or the company. Datalab pays top-of-market salaries; Paruchuri questions the practice of raising $20 million and then paying $150K–$200K salaries rather than hiring fewer people at higher compensation. Broad scope is another part of the offer: people can work across the stack and ship complete things. That attracts some candidates and causes others to opt out. Screening therefore looks for both low ego and the habit of shipping, rather than merely talking about it.

Paruchuri finds that distinction harder to assess remotely. More generally, his worst hiring decisions came when he felt compelled to fill a role quickly, while his best came from finding a strong generalist even without an immediate opening. He compares it to the NBA and NFL drafting debate: choose the best available player or draft for a specific fit. In his experience, patience produces better hires than urgency.

Growth can then mean increasing what each person can accomplish:

• Compensation: raise salary bands as the company grows, bringing more experienced people into the same roles.
• Compute: give researchers more capacity to run their work. Paruchuri contrasts access to eight GPUs with access to 64 as an example of greater resources per researcher, without reporting a measured productivity multiplier.
• AI tools: pay for tools that handle peripheral work and expand what the team can deliver.

He closes the prepared talk by inviting people who want to work this way to contact him through the social accounts shown on his slide.

The first audience question adds an essential qualification to the Dataquest story: did the smaller team keep the same responsibilities? Paruchuri says the high-level product remained the same, but the company removed less relevant features and accumulated peripheral work. The productivity account therefore includes a reduction in scope, not just fewer people doing an unchanged set of tasks. He argues that excess capacity can encourage organizations to invent work, whereas a tiny team has to prioritize ruthlessly.

Another question asks how he would change a century-old company with hundreds of thousands of employees, comfortable revenue, bureaucracy and entrenched egos. Paruchuri says he has not led that kind of transformation. His suggestion is for people who want a different culture to start a small competitor and build the product better. Drawing on his experience at the State Department, Pepsi and UPS, he is skeptical about changing a culture once it has become deeply entrenched.

The audience pushes back: incumbents can buy those startups and crush them. He acknowledges that this sometimes happens and offers Google as a counterexample. This exchange leaves a boundary around his advice: it comes from building small organizations, rather than from a tested method for transforming a large one.

Where do these generalists come from? Speaking publicly is one channel—the talk itself is an example. Open source and Twitter have also brought strong candidates to Datalab. Paruchuri jokes that he refuses to call Twitter X, then describes the more useful mechanism: publish good work and explain how it is built, and people who care about the mission and working style can find you. He presents that as his experience, not a complete sourcing formula.

The interview process tests collaboration through progressively more concrete work:

1. Have a short peer conversation. Discuss a real challenge and see whether the candidate and team can reason through it together.
2. Choose and build a paid project. Paruchuri says the project usually takes about 10 hours and pays $1,000. The team then reviews the work.
3. Spend time with the team. If the project goes well, assess how everyone interacts as people. A good fit leads to a hire.

The project makes the ability to build together observable before either side commits to an ongoing working relationship.

Asked about the success rate, Paruchuri explains that candidates enter this process only when the team already has high confidence in them, to avoid wasting anyone’s time. He estimates that Datalab hired approximately 40% of the people it interviewed. That denominator is interviewed candidates, not all applicants: the evaluation process begins with substantial prior confidence and uses shared work to test it.