How many people are needed to develop a web product in 2026: breakdown of a viable team composition

Hi, tekkix! What prompted me to share this breakdown is the hot topic — "AI will replace all developers" — and feedback from an interview at one of the companies. The AI thesis is repeated at conferences, it is heard by CTOs of mid-sized companies, and they come to hiring with a ready-made solution: "assemble a team of two senior fullstack developers, the rest will be covered by the neural network." And when the need to scale arises, they are surprised that the project budget goes into a tailspin.

My name is Natalia Lebedeva, I have been working in cross-functional scrum teams for over ten years. Over this time, I have developed a team composition that easily survives the first year of stable development and is ready to scale at any moment. In the article, I will explain why exactly so many people are needed, where and when you can save on headcount, what AI cannot do, and how the work of each role changes when a tool like Cursor or Claude Code joins the team.

Disclaimer: this article is about teams for medium-complexity web products (SaaS with users, payments, personal accounts, integrations) in the context of the Russian market as of May 2026. Highload, mobile development, ML teams are a separate story with their own metrics. The AI tools I rely on: Cursor, Claude Code, GitHub Copilot in assistant and autonomous agent modes.

Business-side product owners and stakeholders are not included in the team composition covered in this article; this article only covers the development team.

And to avoid confusion, the article is based on three stages of the product life cycle:

• MVP / hypothesis validation. The goal is to find out if the product is needed by the market and find the first paying users. The timeline is 3–6 months.

• Growth stage. The hypothesis has been confirmed, the first users are coming in, the backlog is growing faster than the team can complete it.

• Full-fledged product in stable development. The product is operational, there are paying users, development proceeds according to plan. The timeline is a year or more.

What AI has actually changed

A real breakthrough was the speed of generating standard (!) code. On simple tasks, a middle developer with an AI agent can complete in a day what used to take them a week. A prototype that previously required a team of 3–5 people, a single developer can put together in a week of evenings, and this is confirmed by developers on Habr describing their own experiments.

So, let's break down the thesis: a development team is not needed, one full-stack developer with AI is enough.

The truth:

• the barrier to entry into development has dropped;

• generating standard code costs less;

• an early prototype can be assembled without a full-fledged team.

What they don't talk about:

• "Writing code" ≠ "building a production-ready system". In production, you can't ignore bugs or technical debt.

• AI has lowered the cost of iteration, but raised the cost of mistakes.

• Vague task formulation paired with AI doesn't give you saved time, but exponentially growing complexity.

It's worth stopping separately on the cost of mistakes. Previously, a bug was assigned to a junior, who spent a day figuring it out, fixing it, and learning the system along the way. Sometimes this was less about fixing the bug and more of an investment in the junior's growth and the team's resilience to the bus factor.

In a "senior + AI" team, the senior fixes bugs. AI helps speed things up, but the neural assistant doesn't learn, doesn't remember context between tasks, doesn't build up understanding of the system, and won't become a middle developer tomorrow. A senior backend developer in the Russian market median (according to data from ENIGMA AI and hh.ru as of early 2026) earns 450–600 thousand rubles per month, or roughly 25–30 thousand rubles per working day. An hour of senior work on debugging instead of an hour of junior work is not just a difference in pay rate, but also a loss of the bug's educational function.

After a year, the team will hit the throughput ceiling of two people. And this isn't "suddenly wanting to expand", but the expected transition to a normal team after the hypothesis is confirmed. At this point, there's a double blow: there's no internal bench of replacements — no one has grown, there's no one to promote. And on the market, over the year, middle/senior rates have risen, as have hiring timelines. The project budget goes into the red again.

What they count on their fingers and what they forget

The idea that "one full-stack developer with AI will replace an entire team" has nice arithmetic:

Previously, a team of five people was needed: frontend developer, backend developer (who also acts as a DevOps specialist), tester, business analyst, designer. Now AI has taken over the routine tasks of each role — standard components, CRUD methods, design parsing, test case generation, documentation templates. That means one senior fullstack developer with AI equals the old five-person team.

But this is where time sinks of a fullstack developer appear, which are usually not taken into account by anyone:

• Context switching. Frontend, backend, database, integrations, deployment, AI code review. Each switch takes 15–25 minutes to restore context, and there are many such switches in a day.

• Task formulation. The more complex the task, the longer it takes to draft the technical specification. A precise prompt is a new subgenre of work, and it eats up real working hours.

• Result validation. AI will agree with almost anything and generate a confident answer to any query. According to the Sonar State of Code 2025, 38% of developers believe that AI code review requires more effort than reviewing a colleague's code. Per the Stack Overflow Developer Survey 2025, 66% of developers regularly spend extra time fixing "almost correct" AI code. The more complex the task, the more costly validation becomes.

• Reviewing a colleague's AI-generated code. Not just for style, but also to check whether the AI agreed with any odd idea (see the previous point).

• Negotiations with clients, documentation, releases, incidents. These also haven't gone anywhere.

And all these points are the responsibility of a single person. If there are enough hours in the day, of course.

And a team is not just a specific number of people, but also:

• bus factor - how many people need to drop out of the process at the same time for product development to grind to a halt

• replacement speed — how many weeks it takes to find a new hire if the current employee quits

• architectural control — who challenges decisions during code review before the code gets pushed to production

• technical debt — who spots it and fixes it

• bench of reserves — who is growing within the team to fill a middle/senior open role from within the team in a year

And there is one more factor that few people think about — cognitive biases. Or in plain terms: "tunnel vision", which everyone encounters. Even AI falls prey to this — the model gets stuck in a loop of its own previous responses during a long session. What can we say about a person who writes the same system for months on end without external review.

A developer stops noticing obvious oddities and errors in the system at the code, architecture, and product level. A solution that an outside reviewer will flag in a minute, the author won't see — for them it fits seamlessly into the overall picture. In a standard team, this is addressed via code review and architectural debates during planning.

In the "one fullstack developer + AI" setup, this is supposed to be handled by AI. Looking at code analysis, I see that AI finds syntax errors extremely well, catches typical bugs fairly well, but it doesn't cure the author's tunnel vision. To get AI to argue the merits of an architectural decision, you need to give it the prompt "argue with me on the merits", but almost no one uses this prompt in day-to-day work. And that's even more true in the "the feature is needed yesterday" paradigm.

That leaves you with a one-person team where no one challenges decisions. This won't show up in the code right away, but it will surface sooner or later.

Basic viable team composition

Now for the key part: the composition I have developed through hands-on practice, and it works at practically any stage of a product's life cycle.

First I will define the terminology to avoid confusion:

• Compressed Model A — 2 senior fullstack + AI. or Compressed Model B — 1 frontend + 1 backend + AI. Cross-skills between team members are desirable for mutual coverage during vacations and sick leaves, but not mandatory. These are the models that are sold at conferences.

• Basic viable is described below. A team that makes it to the scaling stage without structural risks.

• AI-first model — (AI architect or ML/AI engineer or system analyst) + multi-agent infrastructure. Cutting edge, still a rarity in mass practice in the Russian Federation. A short block about it is at the end of the section.

Both compressed models are operational during the hypothesis validation stage. The basic model is used during stable development. They do not compete with each other, as they are applicable for different stages.

Basic composition:

• 1 team lead (management + code review + assistance with architectural decisions)

• 2 frontend developers

• 2 backend developers (at least one with knowledge of DevOps practices)

• 1 system analyst

• 2 testers (one manual + one automation engineer; at the start, the automation engineer also tests manually until the autotest infrastructure is scaled up)

• 1 designer

• 1 DevOps engineer

This is 10 people.

Cost of the composition at the median of the Russian market (May 2026, net):

Total: 2,190,000 – 3,300,000 ₽/month depending on grades.

The upper bound figures are for the senior stack. If we start from the minimum viable: about 2.2 million ₽/month. This is the level at which the product lives without structural risks.

Principles by which this composition is assembled:

1. Tech lead is a separate role. This includes workload management, processes, architectural decision reviews, helping the team resolve technical disputes, incident analysis, and hiring. It is possible to combine this with writing code, but it is not advisable — for a team of 10 people, the tech lead quickly becomes a bottleneck if they write code themselves.

2. Two frontend and two backend developers — for resilience against the bus factor and for code reviews. Having one person per role is like a product running in house of cards mode: if they leave, get sick, or burn out, there is no product. Two people per role provide interchangeability and high-quality internal role reviews. At least one of the backend developers must know DevOps practices — this compensates for the bus factor 1 risk for the DevOps role: you won't have to set up infrastructure from scratch, but the backend developer will be able to support the existing infrastructure when the DevOps specialist is on sick leave or vacation.

3. Two testers with different specializations deliver cost efficiency and interchangeability. A manual tester costs 120–180 thousand rubles (mid-level), while an automation tester costs 160–230 thousand rubles. Two testers with different specializations result in a saving of 40–50 thousand rubles per month compared to hiring two automation testers. And you always need a manual tester — for exploratory testing, UX checks, and non-standard scenarios. This work can be assigned to an automation tester, but not every automation tester will agree to spend part of their time on manual testing on a permanent basis. Interchangeability is a side effect: if the automation tester is unavailable, a backlog of regression automated tests will accumulate, but the situation is not critical, as the manual tester covers current testing. If the manual tester is unavailable, the automation tester temporarily puts off writing automated tests and covers the gap manually, since they started out in that role.

One person can cover adjacent tasks in the short term, but cannot do so equally well and sustainably over a long period at the same time. This same principle applies to any role with cross-functional skills.

4. One systems analyst. My rule:

   • Good — when there are 2 systems analysts for every three pairs of frontend + backend,

   • Ideal — 1 systems analyst per frontend + backend pair.

   In the baseline setup, that is two pairs — meaning one analyst who breaks down business tasks into technical requirements and writes task specifications for developers. Without him, developers decide "what to build" on their own, which creates room for technical debt and future rework. The bus factor for the analyst role is offset by the fact that the team lead and/or team architect must be able to take over this work.

5. One designer. If a design system and standard interfaces are planned for the product, one designer is enough. The design system pre-builds components for a year ahead, the team then assembles interfaces from them, and the designer gets involved in complex screens and iterations. If the product has a deep UX component (user research, non-standard scenarios), you already need two people.

6. One DevOps engineer. That is sufficient at the start. When the infrastructure becomes more complex (multiple environments, 24/7 monitoring), a second one will be needed.

When scaling (as the product grows):

• For every new mid-level frontend + backend pair, one systems analyst and one tester are added. Juniors can be hired for each role both all at once and gradually as the product's value and number of paying customers grow.

• The number of DevOps engineers doubles when the infrastructure moves to multiple environments, active CI/CD and 24/7 monitoring.

You can reduce the team size from the baseline, but every step down requires deliberate risk management. The smaller the team, the more attention you need to pay to stability: every person's absence is felt more strongly, every mistake is more costly, every decision is less contested.

This team composition does not claim to be a universal formula, but it is a working specification of the general Scrum framework (5–10 people, cross-functional, Scrum Guide) tailored for a medium-complexity web product on the Russian market. Other teams may have different proportions.

One important note about team size.

The baseline team composition is a compromise between budget and sustainability. A team wider than the baseline burns through the budget faster, while a team that is too small will see the product fall behind the market and lose value as well.

A separate topic is the AI-first model.

A team of 1-3 people (AI architect, or ML/AI engineer, or systems analyst) and a multi-agent infrastructure where agent roles are split: one writes code, another creates tests on demand, the third does code reviews. Frameworks like MetaGPT, LangGraph and CrewAI already make this technically feasible. Gartner forecasts that 40% of enterprise applications will have task-specific agents by the end of 2026. At the same time, when it comes to corporate AI pilots, the reality is as follows: according to the Camunda 2026 State of Agentic Orchestration & Automation Report (a survey of 1 150 IT executives), 71% of organizations report using AI agents, but only 11% of agent use cases have made it to production over the past year. The main blockers are trust and manageability: 84% are concerned about AI business risks without IT oversight, 80% note insufficient transparency, and 66% cite issues with regulatory compliance.

In this model, each role is highly specialized and rare in the Russian market, with a bus factor of 1 per role. There is still limited systematic data on the performance of AI-first teams for medium-complexity web products, so it is too early to draw conclusions, but we are keeping a close eye on the situation.

4. From the lean model to the baseline team

Both compressed models are about 2.5 times cheaper than the base one.

Where compressed models are justified (both):

• Startup speed. Two senior fullstack developers can be hired in 2-3 months — this is a single hiring stream for one position with two slots (HeadHunter, Q1 2025: senior — 73 days, middle — 58 days to close a vacancy). Assembling a base team of 10 people involves seven different positions, each with its own hiring process, load on interviewers, and onboarding. Optimistically, it takes 3-4 months to reach operational readiness. At the hypothesis validation stage, when every day costs money, this is a decisive advantage of the compressed model.

• Low communication costs. Brooks' Law (Frederick Brooks, «The Mythical Man‑Month», 1975) — the number of communication channels in a team grows quadratically with its size: for n people, there are n*(n-1)/2 channels. Two people have 1 channel. Ten have 45 channels. Fifty have 1,225. This explains why "let's double the team — it will be twice as fast" doesn't work.

• Low cost of ownership until hypothesis validation. Saving 1.3+ million rubles/month over 3 months equals around 4 million rubles that can be spent on a full team once the hypothesis is validated.

• Pivot flexibility. Two people can easily adapt to a change in the hypothesis.

Weak points of compressed models:

• Bus factor = 1. In a two-person team, the loss of one member for a long time is almost a guaranteed burnout of the second. Illness, vacation, conflict, dismissal - any of these turns the work process into a crisis. In team A (2 fullstack) the loss is felt less than in team B (1 front + 1 back), but in both cases, luck controls the risks more than the structure.

• Cognitive ceiling. Two people have a physical limit: it is impossible to grow infinitely in speed and number of tasks. Long-term work at the limit leads to burnout and then the team expansion happens not according to plan, but in an emergency, often at the worst moment of the project.

• Cognitive biases and AI echo. Fullstack writes, AI agrees with him. Decisions are made faster, but go through fewer filters. After a few months, this manifests itself as accumulated architectural errors that the author does not notice.

• Hiring narrow roles - immediately senior. When the team hits the ceiling and needs to add QA or DevOps, there is almost no choice: take a senior who already knows how to build a function from scratch or take a middle one and lay down time for "get bruised" under the direct support of the team lead.

Hidden cost 1: bus factor.

The time to search for a senior developer through the open market in the Russian Federation is 3-4 months (according to vc.ru and New Staff, 2025). In a team of two people, the departure of one is work with one hand without review for 3-4 months, and this is only until the new person starts working. Until full productivity, he needs a few more months - and here the most interesting thing begins.

Hidden cost 2: time to form neural connections for a new person.

Some CEOs think that a week for onboarding is enough. From a biological point of view, everything is much more complicated.

Phillippa Lally with colleagues from UCL (European Journal of Social Psychology, 2010) investigated how long it takes the brain to form a stable automatic behavior in a new context. The average result is 66 days. Range - 18–254 days.

This is about work speed without needing to make a conscious effort every time to think “where this service is hosted, how we call this function, who to write to about deployments”.

Here's how that falls on developers:

• SHRM (Society for Human Resource Management): new employees reach full competency in 8–12 months without structured onboarding. With structured onboarding — 4–6 months. That means even in the best case, this takes months, not weeks.

• Toolfox.ru: without structured onboarding, a developer spends 3–6 months figuring things out on their own and works at 30–40% capacity.

• Daily.dev (2026): the benchmark for a senior engineer is around 12 weeks to reach full productivity; if it takes longer, that is a sign the onboarding process needs to be restructured.

• DX Research (September 2025): even with daily AI use, a new hire submits their 10th pull request in 49 days. Without AI — 91 days. AI speeds up the process, but it does not eliminate the ramp-up period.

During this time, the following takes shape in a new team member's mind:

• Product architecture

• Domain model (how the business is structured, its user base, and its key scenarios)

• Code writing style and the team's unwritten conventions

• Which colleagues are responsible for what, and who to write to about specific questions

• Company goals and current priorities

• Even colleagues' names and roles are a separate cognitive load during the first few weeks

A new developer is literally unable to work at full capacity for several months, as biology takes its course. In a team of 10 people, the same onboarding process is distributed thanks to a lower bus factor, so it does not halt product development.

5. When a compressed model is still justified, and in what order to hire the core team

A compressed model is a working tool at the early stage:

• you are testing a hypothesis

• product with limited scope of liability and/or standard functionality

• product without sensitive data / financial transactions / high uptime requirements

You risk the quality and stability of the product if:

• there are paying users

• you plan to expand functionality

• you plan to work without QA for a long time and the product is non-trivial

• you are not ready to start transitioning to a proper team as soon as the hypothesis is confirmed

The process of hiring a core team is built based on the task's production workflow:

1. System analyst. Since the business task no longer fits in the head of a single PM/Founder, someone needs to break it down into technical requirements and keep architectural boundaries, otherwise development goes by intuition, which creates room for future reworks.

2. Backend (or frontend — based on the results of distributing the current pair of fullstack developers) takes on the task after analysis. Before hiring, the team decides which of the current two fullstack developers specializes in what. We hire whoever is missing.

3. Tester (QA engineer) is brought in once the feature is already implemented. Until that point, the backend developer checked their own work, but building a testing strategy, regression model, and supporting the test environment are not part of their responsibilities. When the flow of features grows, this becomes a bottleneck and there is a need for a dedicated tester.

4. DevOps engineer. When the infrastructure becomes more complex (multiple environments, active CI/CD, monitoring), the backend developer with knowledge of DevOps practices can no longer support the infrastructure without harming their core work.

5. Designer (now, but it is better to hire them in parallel with the backend if the product is UX-critical) will create a unique UI and develop high-quality UX. They will get ahead on tasks so that the frontend does not sit idle.

6. Frontend developer. Will code the layout and bring the mockup to life. We hire them last, because the designer and backend need a head start, and/or the second fullstack developer will handle the first dedicated frontend tasks at the early stage.

You can break the chain at any stage if you have poached that long-sought star from the market and are ready to pay for their downtime just so they don't go to competitors. This applies to any role on the team.

6. What AI actually changes in a team

In a basic team, every role can be augmented by AI: Cursor, Copilot, Claude for developers; AI assistants for generating tests, documentation, and analytical specifications. But this implementation requires internal team guidelines for AI use — what to write as a prompt, what to do manually, how to validate results, and how to review AI-generated code from colleagues.

• Developer spends less time on boilerplate code, but more time on tasking AI, validating results, and reviewing colleagues' AI-generated code.

• Analyst becomes the provider of technical specifications (TS) for both the developer and AI via the developer. The quality of tasking directly impacts speed, because AI requires precision — vague TS produces vague results.

• Tester: automation engineers write tests faster, manual testers find scenarios faster. But decisions on "what is important to test" and "what risks exist in production" are still made by humans. AI generates test cases, but it doesn't know which ones are critical for the business.

• DevOps sets up standard pipelines faster, generates configs, and troubleshoots logs faster. But infrastructure architecture, stack selection, and scaling decisions are still made by humans.

• Designer generates variations and tests hypotheses faster. But design system management, research, and UX strategy are handled by humans.

• Team lead prepares meeting materials faster, reviews large volumes of code, and drafts feedback faster. But decisions on hiring, prioritization, and conflict resolution are human work.

Conclusion

The minimum viable team size for long-term stable development of a web product is 10 people. The cost is around 2.2 million rubles per month at the lower end.

Compressed models from two AI developers are an early-stage tool (3–6 months, hypothesis validation). Outside of the specific context they are used in, they are not scalable, and trying to use them over a long time horizon means taking on technical debt that will need to be paid off over the course of a year.

Common 2026 practice: compressed models for hypothesis testing, and a baseline viable product at the stable phase. The cutting edge is an AI-first model with multi-agent infrastructure, but this is still an experimental path with no stable performance metrics to back it up yet.

So why can't you "fire all developers, leave only analysts/fullstack engineers working with AI".

LLMs are probabilistic models. The same prompt can produce different code from run to run, and this is not a bug, it is a fundamental property of the architecture. This is proven in research Ouyang et al. (ACM TOSEM, 2025): across 829 tasks on three benchmarks, identical prompts produce semantically and structurally different code. At the same time, according to data from Guild.ai (2026), only 21.1% of code generation research takes this factor into account in experiments at all.

In production this means: even with a perfect technical specification, there is a non-zero probability that AI will generate plausible but incorrect code. You can reduce this probability (with temperature=0, structured outputs, validators) — you cannot eliminate it entirely. The principle the industry is deriving from this is: generate probabilistically, validate deterministically — generate using probabilistic methods, validate using deterministic methods. Without role separation, independent validation disappears. And we also remember that AI cannot be held responsible for incidents.

What is the team composition at your company?

Sources

All links to salary aggregators and reviews are included in the body of the article. Here are academic and industry sources with full bibliography:

• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Analysis of «Brooks' Law»: Communications of the ACM.

• Lally, P., van Jaarsveld, C. H. M., Potts, H. W. W., & Wardle, J. (2010). How are habits formed: Modelling habit formation in the real world. European Journal of Social Psychology, 40, 998–1009.

• SHRM — a study of time to full competence in structured and unstructured onboarding.

• Toolfox.ru — a guide to employee onboarding.

• Daily.dev — developer onboarding playbook 2026.

• DX Research (September 2025) — a study on how AI cuts developer onboarding time in half in enterprise companies.