Dedicated Team vs Project-Based Outsourcing: Choose by Scope Stability

Two different things you can buy

Project-based outsourcing (also called fixed-scope or fixed-price outsourcing) sells a result. You hand over a specification, the vendor estimates it, adds a margin for risk and commits to a price and a date. Inside that box the vendor decides who works on it and how. Changes go through a change request: a new estimate, a new price, sometimes a new date.

A dedicated team sells capacity. You pay a monthly fee for a group of engineers who work only on your product and take priorities from you. Scope is a living backlog, not a contract appendix. If you change your mind on Tuesday, the team works on the new thing on Wednesday. The cost of that freedom: the vendor doesn't promise a total, and the outcome is yours to steer. We list what that model gives you in the advantages of a dedicated development team.

Why scope stability decides it

Every software project learns things after it starts. Users react to the first demo, a third-party API behaves differently than documented, a competitor ships a feature, the sales team signs a client with one extra requirement. Capers Jones, whose estimating research is still the most cited on the subject, found that requirements grow by roughly 1–2% per calendar month after they are first written down. On a nine-month project that is 10–20% more work than the contract describes, before anyone changes their mind about anything big.

Both models handle that growth, but they charge for it differently.

• A fixed-price vendor protects itself twice: with a risk buffer inside the original quote (15–30% is typical in the proposals we see), and with change requests priced at the vendor's rate, often 20–40% above the blended rate of the original estimate because they disrupt a plan. Each change also costs calendar time for estimating and approval.
• A dedicated team absorbs change as part of normal work. A new requirement goes into the backlog, something else moves down, and the monthly invoice stays the same. The cost of change is real (the delayed work), but nobody adds a margin to it.

That gives a simple rule: the more your scope will move, the more the fixed-price model charges you for moving it. With stable scope, the risk buffer is a fair price for certainty. With volatile scope, you pay the buffer and then pay again for every change.

There is a quieter cost too. In a fixed-price contract, the vendor's incentive is to say "out of scope" whenever possible, and yours is to argue that everything was implied. That negotiation consumes the goodwill and the attention of the best people on both sides. We see it in first calls with companies leaving a fixed-price vendor: the code is often fine, the relationship is exhausted.

What change actually costs: a worked example

A US logistics startup gets a fixed-price quote of $180,000 for a customer portal and a mobile app, six months. The underlying effort is about $150,000 of engineering; the rest is the vendor's risk buffer. Three months in, after pilot customers try the beta, the startup needs a reworked onboarding flow, a role system for enterprise accounts and an integration with a second carrier API. Together that's about 20% more work.

• Fixed price: the change requests come in at the vendor's change rate, 25% above the original blended rate: $180,000 × 20% × 1.25 = $45,000. Total: $225,000, plus three to four weeks lost to estimating and approving the changes.
• Dedicated team: the same people, billed monthly, without the buffer. The effort was $150,000; add 15% for the estimation drift a T&M engagement typically sees, 20% for the changes, and 10% for the founder's extra time as backlog owner: $150,000 × 1.15 × 1.20 × 1.10 = about $228,000.

At 20% change the two models cost almost the same, and the break-even sits near 28%. Below it, fixed price wins. Above it, the dedicated team pulls ahead quickly, and it also keeps the calendar. Change the inputs below to your numbers.

Budget predictability: two different kinds

"Fixed price gives me a predictable budget" is the most common reason US buyers ask for it, especially when a board or a grant sets the number. It's true, with a qualification: fixed price makes the total predictable for the scope written in the contract. If the scope holds, that's the best predictability you can buy. If it moves, the total moves too, through change requests, and the predictability you paid for in the risk buffer is partly gone.

A dedicated team gives a different kind of predictability. The monthly burn is fixed and known: four people cost the same in March as in April. What's uncertain is how much scope that burn buys. You manage that with a prioritized backlog and a release plan, so the most valuable work lands first and the budget runs out on the least important items, not the most important ones.

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 and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Ownership: what you hold at the end

Code and IP should belong to you in both models. A contract clause settles that, whatever the model, and any vendor that resists it is a vendor to skip. The software outsourcing contract guide lists the wording. The real ownership difference lies in everything around the code:

• Decisions. In a project, the vendor makes the technical decisions within the spec, and you see the result at milestones. In a dedicated team, you see and influence decisions every sprint.
• Knowledge. A project team moves to the next client after acceptance. The knowledge of why things are built the way they are leaves with them unless documentation was a paid deliverable. A dedicated team keeps that knowledge on your product.
• The delivery outcome. Here the project model gives you something the team doesn't: someone else is accountable for hitting the scope, price and date. In a dedicated team, a slipped release is your planning problem, not a breach of contract.
• What happens next. After a fixed project you own software and need someone to run and evolve it. After a year with a dedicated team you own software and a team that knows it.

Where each model fits

Put scope stability on one axis and how long the work will last on the other, and four zones appear. Two of them have a clear answer. The other two are where the hybrid earns its place.

Score your scope stability

Move each slider to where your project stands today, not where you hope it will be after the spec is done. The score combines the factors that, in our experience, best predict how much a scope will move after signing.

The hybrid: fixed discovery, then a dedicated team

Most of the products we see in first calls land in the middle band: they know the goal, have some designs, but haven't tested the details with users. Fixing a price on that is guessing; starting an open-ended team on it can feel like writing a blank check. The hybrid splits the decision in two.

1. Fixed-price discovery (2–6 weeks)A business analyst, a tech lead and a designer turn the idea into user flows, a prioritized backlog, an architecture outline, a risk list and an estimate range. Market prices for this in 2026 run from roughly $8,000 to $40,000 depending on length and team. Our business analysis work is built for this step.
2. Decide with evidenceIf discovery produced a stable, testable scope under six months, put it out as a fixed-price project. If it showed that the product will keep changing, which is the usual result for new products, start a dedicated team.
3. Start small, keep the peopleBegin with the core of the team (often the tech lead from discovery plus two or three developers) and add roles as the backlog proves the need. Keeping the discovery people avoids a handover that loses half of what was learned.
4. Use fixed price for satellitesOnce the team runs, bounded side pieces (a marketing site, a one-off data migration, an integration with a fully documented API) can still go out as small fixed-price projects, to the same vendor or another.

Discovery has a second benefit that's easy to miss: it's a cheap test of the vendor. Two to six weeks of working together tells you more about communication, honesty and engineering quality than any number of sales calls.

Signs you picked the wrong model

Models can be switched, and the earlier the better. These are the symptoms we see when companies come to us mid-engagement.

FAQ

Where Gilzor fits

We run both models and often both for the same client: fixed-price discovery or audits, and dedicated teams for the build and what comes after. 98% of our work is delivered on time, which in fixed-price work means the date we quoted and in team work means the release we planned for the sprint. When a scope is stable enough for a fair fixed quote, we say so, even if the team would be the bigger contract.

Our teams work from Poland and Cyprus. For US companies that is offshore with a fixed daily overlap window, typically the East Coast morning, which we agree in writing before any work starts. For a broader view of the options, see our map of software development outsourcing models.