Dedicated Development Team Structure: Roles, Ratios and Team Size by Stage

The roles, and what each one actually does

Job titles vary between vendors, but the work that needs doing doesn't. Here is every role you're likely to see in a dedicated team proposal, what they're responsible for, when you need them and the 2026 rate range we see for Central and Eastern European vendors. Rates are per hour, through a vendor, and vary with seniority and stack.

Specialists such as ML engineers, data engineers, security engineers or solution architects join when the product needs them, often part-time. An AI feature, for example, usually needs one ML engineer working next to the back-end developers rather than a separate team.

Who sits where: your side and the vendor's side

A dedicated team is not a black box behind a project manager. The structures that work give your people direct lines to the team for product and technical decisions, and keep people management on the vendor side.

Two variations are common. If you have no CTO, the vendor's tech lead takes architecture ownership, and you should plan an independent technical review once or twice a year. If you have a strong engineering manager and only need developers, the vendor PM disappears and the setup becomes closer to staff augmentation; we compare the two in staff augmentation vs consulting.

How the structure changes by stage

The right team for month two is wrong for month eighteen. The most expensive structural mistake we see is a growth-stage team hired on day one: nine people waiting for decisions that haven't been made, burning $70,000 a month while the product owner writes specs. The opposite is common too: an MVP team of three still trying to ship, support and test a product with 50,000 users.

Ratios that hold up in practice

Ratios are where most team proposals go wrong, usually by leaving out QA to make the price look better or by adding a full-time PM to a team of three to make it look managed. These are the ranges we use as defaults, normalized to a team of six developers.

QA to developers: 1 to 3–5. Below one QA engineer per five or six developers, testing turns into a queue at the end of every sprint and bugs reach users. Products with payments, regulated data or many device combinations sit closer to one for three. On our teams, about 5% of tasks sent to QA come back to developers; that low number depends on developers testing their own work first, not on QA being thin. More on how we staff testing on the quality assurance page.

Tech lead: 1 per team, up to about 8 engineers. Beyond that, code review alone takes most of their week. That's one of the signals it's time to split.

Project manager: 0.25–0.5 FTE for a small team, one per one or two teams. A full-time PM on a team of three spends the extra time producing reports nobody needs. Our project management engagements scale with the team for this reason.

Senior to mid-level developers: roughly 1 to 2. All-senior teams are expensive and often bored by routine work; all-mid teams make architectural decisions they can't yet foresee the cost of. Junior developers can work in a dedicated team when there are enough seniors to review their code, but rarely make sense for a short engagement.

Build your team: headcount and budget

Pick your product type, stage and rate region. The builder applies the stage structure and ratios above and shows the roles, the headcount and a monthly budget. It's the same first-pass logic we use before a scoping call. The real answer depends on your backlog, but this gets you within the right range.

A few things the builder makes visible. Moving from MVP to growth roughly doubles the team and the budget, which is why that step should follow evidence (users, revenue, a funding round) rather than a calendar. An aggressive deadline adds developers and, through the ratios, QA, so “just add two developers” is never only two people. And the jump from CEE to onshore rates is bigger than any change in team shape you could make. For a country-by-country view, see nearshore software development rates.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Real estateModernizing a Multi-Service Real Estate Marketplace→FinTechAndroid application for FinTech industry→Pharmacy · DACHRedesigning and modernizing an Online Pharmacy mobile app→

Talk to the people who build it. Tell us about your project — get a free estimate of scope, timeline and cost.

Get a free estimate →

Three ways to organize the team

Once a team grows past five or six, how you organize it matters as much as who's on it. These are the three shapes we see, in order of how often we'd recommend them.

A good rule for squads: organize around something a user would recognize (onboarding, payments, the mobile app, the admin panel), not around a technology. When a squad can ship its feature without waiting for another squad, the structure is right.

When to split the team

The Scrum Guide suggests ten people or fewer per team, and in our experience the practical limit for one standup is lower, around eight or nine. The math explains why: a team of six has 15 communication paths, a team of nine has 36, a team of twelve has 66. Output doesn't grow nearly as fast.

Signs that it's time to split, even below that size:

• The daily standup regularly runs past 20 minutes, and half the team tunes out during the other half's updates.
• The tech lead spends most of the week reviewing code and has stopped writing any.
• Two clearly separate streams of work exist, such as a new mobile app and the existing web product, and they compete for the same sprint.
• Planning takes more than two hours because nobody can hold the whole backlog in their head.

Split along product areas, give each new squad its own lead and QA, and keep one product owner, one release process and one shared demo. The first two sprints after a split are usually slower. By the third, both squads should be shipping more than the single team did.

Structure mistakes we see in first calls

These come up again and again when companies bring us a team that isn't working, or a proposal they're unsure about.

• No QA, to keep the price down. The developers test their own work, bugs reach users, and the product owner becomes the QA team. It's the most expensive saving in software.
• No tech lead. Five developers of equal seniority, each making architecture decisions in their own corner. It works for three months, then every feature touches something someone else built differently.
• A team sized for the roadmap, not the decisions. Nine people hired before the product owner has written the first epic. Half of them spend the first month on “research”.
• All juniors with one senior. Cheaper per hour, more expensive per feature. The senior spends the whole week reviewing and fixing.
• The product owner outsourced to the vendor. The vendor PM can run the process, but decisions about what your product does should stay with you.
• No one owns DevOps. Fine for an MVP. At growth stage, it shows up as releases that take a day and environments nobody dares to touch.

If one of these sounds familiar, an outside view helps. Our tech troubleshooting service reviews a struggling team's code, process and structure and comes back with a written plan. For the hiring side, see how to hire a dedicated development team; for running the team once it's in place, how to manage a dedicated development team.

FAQ

Where Gilzor fits

We assemble dedicated teams around the product and the stage, not around who happens to be on the bench: a discovery crew for two to six weeks, a small senior MVP team, then QA, PM and design added as real users arrive. Development starts within two weeks of signing, and we've launched more than 70 products this way with startups and SMBs over the past seven years.

If you'd like a second opinion on a team structure, yours or a proposal you've received, send it over. We'll tell you what we'd keep, what we'd change and what it would cost. More about how we extend and run teams on our development support page.