Choose project-based delivery when the scope is defined and has an end, a dedicated team when you have a continuous roadmap and want a stable external squad that works as yours, and staff augmentation when you have strong internal leadership and need capacity, not ownership. In 2026 a dedicated team of five costs $40,000 to $70,000 (€35,000 to €60,000, £30,000 to £50,000) per month nearshore and $90,000 to $150,000 (€80,000 to €130,000, £65,000 to £110,000) per month onshore. Most enterprise programs start project-based and move to a dedicated team after the first release.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Every external software engagement is one of three shapes: you buy an outcome, you rent a team, or you borrow people. Vendors blur the lines because each shape suits them at different times, and buyers pick the wrong one because the decision is made at procurement rather than by the people who will run the work. This post is for the technology or operations leader choosing how to engage a partner for a build, a modernization or an ongoing roadmap. It compares the three models, gives the numbers, and offers a decision rule that holds up.
What are the three engagement models?
- Project-based. You define a scope, the vendor commits to deliver it for a price and a timeline, fixed or estimated. The vendor owns delivery and the team composition. It ends when the scope ships.
- Dedicated team. You retain a named, stable team for a monthly fee. They work on your roadmap, usually with their own lead and process, and you direct priorities. It has no end date by design.
- Staff augmentation. You hire individual engineers through a vendor to work inside your own team, under your management, your process and your tools. You own delivery entirely.
How do they compare?
| Dimension | Project-based | Dedicated team | Staff augmentation |
|---|---|---|---|
| You buy | An outcome against a scope | A stable team's capacity and judgment | Individual capacity |
| Who owns delivery | Vendor | Shared, vendor lead runs the team, you set priorities | You |
| Control over scope | Low once signed, changes go through change control | High, reprioritize each sprint | Total |
| Cost predictability | Highest for the defined scope | Fixed monthly, variable output | Fixed per person, variable output |
| Ramp-up | Discovery phase, then build | Four to eight weeks to full productivity | Two to six weeks per person |
| Risk you carry | Scope being wrong | Under-using the team | Everything, including management bandwidth |
| Typical cost | $80,000 to $200,000 (€70,000 to €175,000, £60,000 to £150,000) to $200,000 to $600,000 (€175,000 to €520,000, £150,000 to £445,000) per phase | $40,000 to $70,000 (€35,000 to €60,000, £30,000 to £50,000) per month nearshore, $90,000 to $150,000 (€80,000 to €130,000, £65,000 to £110,000) onshore, for five people | $45 to $90 per hour (€40 to €80 per hour, £35 to £65 per hour) nearshore, $120 to $220 per hour (€105 to €190 per hour, £90 to £165 per hour) onshore per person |
| Best for | A defined build or migration with an end | A product or platform with a continuous roadmap | A strong internal team that needs hands, not direction |
When is project-based the right call?
When the work has a boundary you can describe and an end you can recognize. A data migration, a replacement of one legacy module, an integration between two named systems, a customer portal with a known scope. The vendor takes the delivery risk, your internal team is not consumed by management, and finance gets a number. The condition is that the scope is actually known, which means a discovery phase has happened, either yours or the vendor's. Project-based delivery on an undefined scope is how change requests become the largest line in the budget. Fixed price vs time and materials covers the pricing side of this model.
When is a dedicated team the right call?
When the roadmap does not end. A product your customers use, a platform several departments depend on, a modernization program that will take two years in slices. The team learns your domain once and keeps that knowledge. You stop paying the ramp-up tax every time a new project starts. And priorities can move every sprint without a change request, which is what business software needs in practice.
The risk is under-use. A dedicated team costs the same in a month when you have no decisions ready for it. Organizations that struggle to make product decisions at a steady cadence should fix that before retaining a team, or start smaller. A team of three with a lead is a reasonable first step.
When is staff augmentation the right call?
When you have an engineering lead who runs a good process and simply lacks people. Augmented engineers slot into your sprints, your repository and your reviews. You get capacity quickly and you keep all the knowledge in-house. The condition is management bandwidth. An augmented engineer with no one to direct them produces little, and the vendor will say, correctly, that direction was your side of the contract.
Augmentation is the wrong model when the real gap is leadership or architecture. Adding four engineers to a team with no technical lead adds four people waiting for decisions.
What does each model really cost?
The monthly figures above are the vendor's fee. The full cost includes what the model demands from your organization:
- Project-based needs a product owner at roughly a quarter of their time, plus stakeholders for reviews. Change requests on a well-scoped build run 10 to 20 percent of the contract and should be in the budget from the start.
- Dedicated team needs a product owner at half-time or more, because the team will consume decisions as fast as you make them. The fee usually includes the vendor's lead, process and tooling.
- Staff augmentation needs an engineering manager's attention per person, onboarding time, and your own tooling and licenses. The lower hourly rate is real, but a team of augmented engineers managed thinly often delivers less per dollar than a smaller dedicated team.
For the hourly rates by region and what sits behind them, see nearshore vs offshore vs onshore.
A decision rule by situation
| Your situation | Start with | Then |
|---|---|---|
| New system, scope not yet defined | Project-based discovery | Project-based build of the first release |
| First release shipped, roadmap continues | Dedicated team | Resize quarterly against the roadmap |
| Legacy modernization over several years | Project-based for the first slice | Dedicated team for the remaining slices |
| Strong internal team, hiring is slow | Staff augmentation | Convert to hires or a dedicated team as the gap becomes permanent |
| One integration or migration with a clear end | Project-based | Support contract after go-live |
| No internal technical leadership | Project-based with the vendor's lead | Dedicated team, and hire a product owner on your side |
How do you switch models mid-engagement?
- Switch at a release boundary. The natural moment to move from project-based to a dedicated team is the go-live of the first release, when the scope is proven and the roadmap is visible.
- Keep the people. The value of the switch is continuity. Ask for the engineers who built the first release to form the core of the team, in writing.
- Change the contract, not the cadence. A master agreement with a new statement of work for the retained team keeps the legal side simple. MSA, SOW and change requests explains the structure.
- Set a review every quarter. Team size, priorities and the model itself. A dedicated team that has delivered the roadmap should shrink to a support arrangement, not run on inertia.
- Plan the exit from day one. Documentation, repository ownership and environment access in your name regardless of model. Who owns the code covers the clauses.
In one line each
- Project-based: the scope is known and it ends. Buy the outcome.
- Dedicated team: the roadmap continues. Rent a stable team that learns your business once.
- Staff augmentation: you lead, you lack hands. Borrow people and manage them properly.
How 7L works across the three models
7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens, and we have supported more than one hundred organizations through every one of these models. Most enterprise relationships start project-based with a discovery phase and a first release, then continue as a dedicated team once the roadmap is clear, and we are candid when a client would be better served by augmenting their own team instead. Whatever the model, the code, the environments and the documentation are yours. If you are weighing how to engage a partner for an enterprise software program, tell us the situation and we will say which shape we would recommend and why.
Frequently asked questions
What is the difference between a dedicated team and staff augmentation?
A dedicated team is a stable group with its own lead and process that works on your roadmap, with delivery shared between the vendor's lead and your product owner. Staff augmentation places individual engineers inside your team under your management, and you own delivery entirely. The dedicated team costs more per person but includes leadership and process. Augmentation is cheaper per hour but consumes your management bandwidth.
How much does a dedicated development team cost per month?
In 2026, a dedicated team of five, typically a lead, three engineers and a shared QA and project management allocation, costs $40,000 to $70,000 (€35,000 to €60,000, £30,000 to £50,000) per month from a nearshore European partner and $90,000 to $150,000 (€80,000 to €130,000, £65,000 to £110,000) per month from an onshore US or UK firm. The fee usually includes the team lead, process, tooling and sprint reporting. Add roughly half of a product owner's time on your side.
Can we start with a fixed-price project and move to a dedicated team?
Yes, and it is the most common path for enterprise programs. Use the project-based phase to run discovery and ship the first release, which proves the scope and the team. Switch at go-live, ask in writing for the same engineers to continue, and set up the dedicated team under a new statement of work on the same master agreement.
What is the minimum size for a dedicated team?
Three people with a lead is a workable minimum: a senior engineer who leads, two engineers, and a share of QA and project management. Below that you are buying augmentation with a different name. Above eight, split into two teams with separate backlogs, because one backlog cannot keep eight people productive without constant coordination.
Which model is lowest risk for a first engagement with a new vendor?
Project-based, starting with a paid discovery phase of three to eight weeks. It gives you a written scope, a confirmed price for the first release and a working view of how the vendor thinks and communicates, for a small fraction of the program cost. If discovery goes badly, you leave with a usable document and no further commitment.