A two-person team can deliver a production LLM application. A six-person team can fail at a computer vision proof of concept. The difference rarely comes down to talent or budget. It comes down to whether the team's composition actually matches the technical demands of the project.
Why headcount is the wrong question
The instinct when a project stalls is to add people. But different AI domains need fundamentally different skill mixes, and throwing generic engineering headcount at the wrong mix does not fix anything. An LLM integration project might be roughly 70% software engineering and 30% ML work. A custom object detection model is closer to the opposite: 30% software engineering and 70% ML. Staff either one like the other, and you end up with a team that is busy but not producing.
Based on staffing patterns across more than 60 AI projects since 2018, a few consistent structures hold up across project types and stages.
Stage 1: Feasibility (4 to 8 weeks)
At this stage, the goal is answering one question: can this actually work? The team should be small and senior.
LLM projects: 1 senior ML engineer, 1 software engineer
Computer vision projects: 1 senior ML engineer, 1 ML engineer
Voice and speech projects: 1 senior ML engineer, 1 software engineer
Two engineers is enough to validate feasibility or ship a well-scoped LLM integration. Adding more people at this stage usually slows the answer down rather than speeding it up.
Stage 2: Development (2 to 4 months)
Once feasibility is confirmed, the team needs to grow, but the growth should follow the project's specific bottlenecks rather than a fixed formula.
LLM projects: 1 team lead, 2 ML engineers, 1 software engineer
Computer vision projects: 1 team lead, 2 ML engineers, 1 data engineer, 1 software engineer
Voice and speech projects: 1 team lead, 2 ML engineers, 1 software engineer, 1 data engineer
Notice that computer vision and voice projects both pick up a data engineer at this stage that LLM projects do not need as urgently. That is not an oversight: those domains typically depend on larger, messier, more custom datasets that need dedicated engineering attention. A team of 4 to 5 engineers plus a team lead is generally what it takes to move a prototype toward production at this stage.
Stage 3: Production (2 to 4 months)
By the time a project reaches production, the composition converges across project types more than people expect: 1 team lead, 1 to 2 ML engineers, 1 MLOps or DevOps engineer, and 1 software engineer. The MLOps role is the one most frequently missing at this stage, and its absence is a common reason projects that worked in development start failing quietly once they are live.
Roles that get under-resourced
A few positions consistently get skipped or treated as optional, and that is usually a mistake:
Evaluation engineers on LLM projects, where without dedicated evaluation, quality regressions go unnoticed until users complain
Data engineers on computer vision and voice projects, where data quality issues are usually the real bottleneck, not model architecture
MLOps engineers at the production stage, where the gap between "works in a notebook" and "works reliably in production" lives
If your team is missing one of these roles, it is worth asking whether that gap is the actual reason for the current bottleneck before hiring more generalist engineering headcount.
Rough sizing by project scale
As a general guide: 2 engineers can handle feasibility work or a well-scoped LLM integration. 4 to 5 engineers plus a team lead can move a prototype to production. 6 or more engineers plus a team lead suit enterprise-scale implementations with multiple integration points and stakeholders.
What predicts success, regardless of team size
Team composition matters, but it is not the only variable. Four factors show up consistently in projects that succeed, independent of whether the team is staffed internally, externally, or as a mix:
Production experience in the relevant domain, not just general ML experience
Explicit evaluation practices defined before building starts
A clear handover plan for who owns the system once it ships
Willingness to reject unfeasible projects early, rather than staffing around a flawed premise
Renting versus building the team
Bringing in outside help tends to make sense for projects with a 3 to 12 month timeline where the required skill mix does not exist internally yet. Building the team internally makes more sense when AI is core to the product and there is enough runway to justify the investment in permanent headcount. Either way, the composition guide above holds: match the team to the project's actual technical demands, not to a generic engineering headcount target.
If you are scoping a project and are not sure what team shape it actually needs, reach out to our team. We have staffed projects across LLM, computer vision, and voice domains, and can help you work out the composition before you commit to a hiring plan.