Skip to content

Insights Team Delivery

Dedicated Team, Fixed-Scope Project or Managed Service? Choosing a Delivery Model in the AI-Assisted Era

The right engagement model decides who carries risk, how fast you learn and what you pay for. Here is how to choose between dedicated teams, fixed-scope projects and managed services in 2026, and how AI coding tools change team sizing.

When companies bring in an external engineering partner, the first question is usually “who?” The more important question is “how?” The engagement model, whether a dedicated team, a fixed-scope project or a managed service, decides who carries risk, how quickly requirements can change, how knowledge is retained and what you actually pay for. Choose the wrong model and even a strong partner will struggle; choose the right one and an average plan can still land well.

In 2026 the decision has an extra dimension. AI coding assistants and agents are now part of everyday development, and they are changing how many people a piece of work needs, which roles matter most and what a reasonable price looks like. This guide compares the three main delivery models, explains where nearshore and offshore setups fit, and offers a practical framework for sizing teams when AI is in the loop.

The Three Delivery Models at a Glance

Most software engagements fall into one of three shapes. Each optimizes for something different.

Fixed-scope project

You agree on a defined outcome, a timeline and usually a price. The partner owns the delivery plan and takes on more of the schedule and cost risk. This works when the problem is well understood: a specified integration, a migration with a known inventory, a product rebuild with a clear feature list. It breaks down when requirements are still being discovered, because every change becomes a negotiation.

Dedicated team

You get a stable, long-running team, typically engineers, QA and a delivery lead, working on your priorities, which you set and change sprint by sprint. You pay for capacity rather than a defined output. Risk on scope sits largely with you, but so does control. This model fits evolving products, platforms with a long roadmap and situations where accumulated domain knowledge is the main asset.

Managed service

The partner takes responsibility for running and improving something, such as an application portfolio, a data platform or cloud operations, against agreed service levels. You pay for outcomes like availability, response times and a volume of enhancements, rather than for headcount. This is the right shape when the work is ongoing and operational, and you would rather buy a result than manage a team.

In short: projects buy a defined deliverable, dedicated teams buy flexible capacity, and managed services buy an operational outcome.

How Risk, Control and Cost Shift Between Models

The models are best compared by asking who absorbs each kind of uncertainty.

  • Scope risk sits mostly with the partner in a fixed-scope project, mostly with you in a dedicated team, and is bounded by the service catalogue in a managed service.
  • Control over priorities is highest with a dedicated team, lowest in a fixed-scope project once the contract is signed, and shared through governance in a managed service.
  • Price predictability is highest for a fixed-scope project if scope truly holds, steady monthly for a dedicated team, and tied to service tiers and volumes for a managed service.
  • Knowledge retention is strongest with a dedicated team or managed service, and weakest after a project hands over and the team disperses.
  • Management effort on your side is highest with a dedicated team (you own the backlog), moderate for a project, and lowest for a managed service.

A common mistake is to pick a fixed price because it feels safe. Partners price uncertainty into fixed bids, so if the problem is not well understood you pay a premium for risk and still face change requests. Fixed-scope works best after a discovery phase has narrowed the unknowns. Conversely, a dedicated team without a strong product owner on the client side can drift, because nobody is making the hard prioritization calls.

What AI Coding Tools Change About Team Sizing

AI assistance is no longer optional or experimental. Google’s 2025 DORA State of AI-assisted Software Development report, based on a survey of nearly 5,000 technology professionals, found that 90% of respondents use AI at work, and more than 80% said it had improved their productivity. Stack Overflow’s 2025 Developer Survey, with more than 48,000 responses, put usage at 84%.

But the evidence on how much faster teams actually deliver is more nuanced than vendor marketing suggests:

  • Perceived and measured speed differ. METR’s randomized trial in early 2025 found experienced open-source developers took 19% longer on real tasks in mature codebases when allowed to use AI tools, even though they believed they had been sped up. In February 2026 METR said it now believes developers are more sped up than its early estimates showed, but described its new data as only weak evidence of the size of that gain.
  • Trust is limited. In the Stack Overflow survey, 46% of developers said they distrust the accuracy of AI output, and the most common frustration was solutions that are “almost right, but not quite.”
  • AI amplifies the system it lands in. DORA describes AI as a mirror and a multiplier: it boosts already well-run organizations and exposes weaknesses in fragmented ones.

For team sizing, the practical conclusions are these. AI shrinks the effort for well-specified, pattern-heavy work: boilerplate, test scaffolding, data mapping, documentation, migrations between similar frameworks. It does far less for ambiguous product decisions, complex integrations, performance tuning in large legacy codebases and anything requiring deep domain judgment. And it shifts effort toward specification, review and verification. Code is cheaper to write and just as expensive to get wrong.

AI coding tools make code cheaper to write, not cheaper to get wrong. Size teams for specification, review and verification, not for typing.

How team composition is shifting

Rather than simply cutting headcount by a fixed percentage, effective teams are changing their mix:

  • Fewer pure implementers, more senior engineers who can decompose problems, write clear specifications and judge generated code.
  • Stronger QA and test engineering, because automated tests are the main defense against plausible but wrong output.
  • More platform and DevEx investment: CI pipelines, environments and guardrails that let agents and humans ship safely.
  • Explicit AI governance: rules on which code and data can be shared with which tools, and how AI-generated changes are reviewed and attributed.

In practice, a team that once needed six implementers alongside a lead and a tester might now deliver similar output with four stronger engineers, a dedicated QA automation engineer and the same lead, but only if the codebase, tests and pipelines support AI-assisted work. Treat any such ratio as a hypothesis to measure over the first few sprints, not a promise in a proposal.

How AI Changes Each Delivery Model

Fixed-scope projects

AI makes certain kinds of fixed-scope work, such as framework upgrades, test-coverage uplift and code migrations, more predictable and cheaper. That is good for buyers, but it raises a new question: who captures the efficiency? If a partner prices by historical effort and delivers with AI, the buyer overpays. Ask how the proposal accounts for AI tooling, and prefer outcome or milestone pricing over disguised hourly rates.

Dedicated teams

AI raises the ceiling on what a stable team can deliver, which strengthens the case for smaller, more senior dedicated teams. It also makes the team’s engineering practices more important than its size. When evaluating a partner, ask to see how AI is integrated into their workflow: review standards, test expectations, security controls and how they measure the effect.

Managed services

In operations, AI is changing ticket triage, root-cause analysis, runbook automation and routine enhancements. Managed service contracts priced on headcount become harder to justify; contracts priced on service levels and outcomes align better with AI-driven efficiency, because the provider is rewarded for automating rather than for staffing.

Nearshore, Offshore and Hybrid: Where Location Still Matters

The location of a delivery team still shapes collaboration, even in a remote-first world. The trade-offs are less about cost alone and more about how work flows.

  • Nearshore (similar time zones) maximizes overlap for real-time collaboration: workshops, pair programming and fast decisions. It suits discovery-heavy work and teams that rely on frequent conversation.
  • Offshore (larger time difference) offers access to deep talent pools and cost efficiency, and can support follow-the-sun handoffs for operations and testing. It needs disciplined written communication and a few hours of planned overlap.
  • Hybrid setups put a product owner, architect or delivery lead close to the client and the core engineering team in a delivery hub, combining responsiveness with scale.

AI tools subtly favor distributed teams that already work in writing. Clear tickets, specifications and acceptance criteria are exactly what AI agents need too. A team that writes good specs for its offshore colleagues is also writing good prompts. Conversely, teams that depend on hallway conversation struggle with both distance and AI.

For buyers in North America, Europe and Asia-Pacific, a Southeast Asian hub such as Hanoi can provide a useful overlap: same-day collaboration with APAC, morning overlap with Europe and an evening or early-morning window with North America, which suits asynchronous delivery with short daily sync points.

A Decision Framework You Can Use

Work through these questions in order. The answers usually point clearly to one model, or to a sequence of models.

  1. How well understood is the problem? If requirements are stable and testable, a fixed-scope project is viable. If not, start with a time-boxed discovery or a dedicated team.
  2. Is the work finite or ongoing? Finite work with a clear end suits a project. A product with a multi-year roadmap suits a dedicated team. Keeping something running suits a managed service.
  3. Who will own prioritization? A dedicated team needs a capable product owner on your side. If you cannot provide one, choose a project or ask the partner to supply product management.
  4. How important is retained knowledge? If the system is complex and long-lived, favor continuity: a dedicated team or managed service, not a series of disconnected projects.
  5. What do you want to pay for? Output (project), capacity (dedicated team) or outcomes (managed service). Align the contract with what you actually value.
  6. How mature is your engineering foundation? AI-driven efficiency depends on tests, pipelines and clean architecture. If those are weak, budget for that work first or the promised gains will not appear.
  7. How much collaboration overlap do you need? Choose nearshore, offshore or hybrid based on how much real-time interaction the work demands.

Many successful engagements combine models over time: a short discovery project, followed by a dedicated team to build, followed by a managed service to run and evolve the result, often with some of the same people providing continuity across all three phases.

Worked Example: A Mid-Sized Retailer’s Order Platform

Consider a generic mid-sized retailer that wants to replace an aging order-management system and add marketplace integrations. Requirements are partly known, partly not, and leadership wants budget certainty.

A fixed-price bid for the full replacement would carry a large risk premium, because nobody yet knows how many edge cases the old system handles. Instead, the retailer starts with a four- to six-week fixed-price discovery: process mapping, an inventory of integrations, a target architecture and a ranged estimate for the build. This is a bounded project with a clear deliverable.

Discovery reveals that the core order flow is well understood but marketplace integrations will keep changing as new channels are added. The retailer therefore chooses a dedicated team for the build: a delivery lead, a solution architect, four senior engineers using AI assistants, two QA automation engineers and a part-time DevOps engineer, with the retailer’s own product manager setting priorities. Because the team invests early in automated tests and a clean CI pipeline, AI tools prove effective for integration adapters and data migration scripts, and the team holds its size steady instead of growing as originally projected.

After launch, operations and routine enhancements move to a managed service with agreed response times and a monthly enhancement allowance. Two engineers from the build team stay on, preserving knowledge. Each phase uses the model that fits its level of uncertainty.

Contract and Governance Checklist

Whatever model you choose, these points protect both sides:

  • Clear definition of done and acceptance criteria, including test coverage and documentation.
  • Change control that is lightweight for dedicated teams and explicit for fixed-scope work.
  • Team stability clauses: notice periods and handover expectations when people rotate.
  • Metrics that matter: lead time, deployment frequency, change failure rate and recovery time, the DORA measures, rather than hours logged.
  • AI usage terms: approved tools, data handling, IP ownership of generated code, review requirements and security scanning.
  • Intellectual property and access: code in your repositories, infrastructure in your accounts, credentials under your control.
  • Exit plan: documentation, knowledge transfer and a transition period so you are never locked in.

Conclusion: Match the Model to the Uncertainty

There is no universally best engagement model. Fixed-scope projects work when the problem is well defined. Dedicated teams work when the product is evolving and knowledge is the asset. Managed services work when the goal is a reliable, improving operation. In 2026, AI coding tools shift the balance toward smaller, more senior teams, stronger testing and outcome-based contracts, but only where engineering foundations are solid enough to absorb them.

Start by being honest about how much you know, how long the work will last and what you want to pay for. Then pick the model, or sequence of models, that puts risk with the party best placed to manage it. That decision, more than any rate card, will determine whether the engagement succeeds.

How Hanoi Technology Can Help

Hanoi Technology delivers software through projects, dedicated teams or managed services from its Hanoi delivery hub, for clients in North America, Europe and Asia-Pacific.

Further Reading

Turn These Ideas into Results

Book a free consultation with our experts. We reply within 24 hours with a practical next step for your organization.