Staff Augmentation vs Managed Services vs Project Outsourcing: Who Owns the Outcome

You can tell which engagement model you bought by who apologizes when the release slips. Under managed services, the vendor apologizes and, when the service level covers the miss, credits your invoice. Project outsourcing gets you the same apology with a change request attached. Under staff augmentation, you do the apologizing, usually to your board.

That is delivery risk, the first of three things an engagement contract decides. The other two cost more when they arrive as surprises.

One is who pays when someone leaves. Under Ohio's public terms, choosing a replacement for a named person can take up to fifteen business days (page 33), and in our experience learning your system takes longer than that. Under staff augmentation your team pays for that learning time by default (Stratoflow), so write the days to a replacement, the seniority and who covers the overlap into the contract before the first person starts.

The other is who owns the code. As we read US copyright law, code written by a contractor, or by a vendor's employee as part of the job, belongs to the contractor or the vendor until a signed assignment moves it to you. That stays true after you have paid the invoice and while the repository sits in your own GitHub organization. In due diligence, investors and buyers expect signed IP assignments from every founder, employee, contractor and advisor.

Here is who owns what under each model, as we read how they work in practice. The sections after the table show the sources.

The three models side by side, by who owns what

The rest of this post takes the rows one at a time, starting with delivery risk.

Delivery risk follows whoever directs the work

In practice, under staff augmentation the vendor sells time and skill. You set the priorities, review the work and decide what done means. That direction is the control buyers want from the model, and the risk comes attached to it: when the plan is yours, so is the slip.

Florida's statewide contract for IT staff augmentation writes that trade down. The state pays the vendor by the hour by default, and the buying agency keeps the right to reject any staff member whose qualifications or performance it judges insufficient (sections 3.12 and 4.1). An agency that wants the vendor to carry delivery risk has to ask for project-based pricing, where payment depends on completed deliverables and tasks (section 9.5).

A well-documented public example of that trade is Cover Oregon, the state's health insurance exchange. Oregon hired Oracle on a time-and-materials basis, with the state serving as its own systems integrator. The state spent about $300 million developing the exchange, and by August 2014 the two sides were in court.

Constellation Research's review of the eventual settlement found the state often left Oracle's deliverables unspecified in its contracts, which weakened its hand when it tried to hold the vendor to account. Independent reports found fault with both Oracle and state officials, and the litigation ended in a settlement in September 2016.

Oregon is a state government and your startup may have ten people, but the mechanics carry over: buy hours, keep the plan, and the plan's failures stay with you, in writing.

As we see it, managed services move the delivery risk to the vendor, inside the service definition. The provider commits to response and resolution times or uptime in a service level agreement, and the contract decides what a miss costs the provider. You keep the product decisions, and the provider decides how the service runs. That suits stable, measurable functions such as support, infrastructure operations and upkeep of a mature product. In our experience a roadmap that changes every sprint fits it poorly, because work outside the agreed service means renegotiating the service definition.

On a fixed price, project outsourcing moves the risk to the vendor inside the scope document. A fixed price for a fixed scope is a real transfer of risk, and it lasts exactly as long as the scope does. On time and materials against an estimate, the overrun stays with you. As we see it, each change request is a small renegotiation that hands some of the risk back to you, and its price comes from the side that knows the codebase better.

So the first question is a practical one: who will direct the engineers every day, and does that person have the hours?

A replacement is a new person learning your system

Finding the replacement is the vendor's job under staff augmentation. Stratoflow's October 2026 comparison says the vendor sends a replacement and the knowledge leaves with the person, and it lists the ramp-up of replacements among the costs that stay with you. A Q3 Technologies guide from September 2026 says it more bluntly: your team carries the transition risk. Two vendors give the same answer, and both stop short of quoting a clause.

The knowledge is the expensive part. Finding a replacement takes time, and learning which module is fragile, why the retry logic looks strange and which customer depends on the workaround in our experience takes longer still. That time is what the replacement clause has to price.

Public contracts show what written terms look like. Ohio's 2015 request for proposals for IT staff augmentation gives an agency a first-week trial: if a new contractor lacks the skills within the first five business days, the agency can have them replaced at once, and that week's work goes unbilled (page 69).

Ohio's standard terms for anyone named in a contract give the vendor five business days to put forward two replacement resumes and the state ten business days to choose one or reject both, and a vendor that pulls a named person off the work for an unapproved reason can owe $1,500 for each day until the replacement starts (page 33). Its service levels set a target of 5% or lower for unplanned turnover, measured quarterly (page 132).

A startup contract can borrow the pattern: name the engineers in the contract, ask for a first week that is billed only if the person fits, and fix the days to a replacement you get to vet.

The clause should answer four things:

• How many working days until a replacement starts, and at what seniority.
• Who pays for the overlap while the new person learns the codebase.
• Whether you interview the replacement the way you interviewed the original.
• Where the context lives: decision records, a written onboarding path, and review history in the repository, where the next person can read it.

Under managed services, the vendor's own people run the service and you see the results in response times, availability and monthly reports, which is what you paid for. Under project outsourcing, a departure is the provider's problem until acceptance. After handover the next person to learn the code is on your payroll, so the handover documentation belongs in the deliverable.

The code belongs to whoever typed it, until someone signs

The paperwork behind code ownership is shorter than most contracts and easier to get wrong. This section is general information about US law, written by engineers. Have counsel read your actual contract.

US copyright starts with the author: the statute says copyright vests initially in the author or authors of the work. The exception is a work made for hire, and the Copyright Office's Circular 30 describes two routes to one. The first is a work an employee creates as part of their regular duties. The second is a specially commissioned work that falls into one of nine categories in the statute's definition, where both sides sign a written agreement that calls it a work made for hire.

The nine are contributions to a collective work, parts of a motion picture or other audiovisual work, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases. Custom application code falls outside all nine, which is our reading of the list and the reading Amundsen Davis gives in its IP alert.

So custom application code written by an independent contractor belongs to the contractor, and code another company's employee writes as part of their job belongs to that company, until a transfer moves it. Apart from transfers by operation of law, a transfer is valid only when it is in writing and signed by the owner of the rights conveyed, or by that owner's authorized agent.

A court has applied that rule to a company's own business software. In a 1992 Second Circuit case brought by a programmer named Clifford Aymes, a chain of swimming-pool stores had hired him in 1980 to write the program it used for cash receipts, inventory, sales and purchase orders. Ownership was left out of the paperwork, he was paid by the hour or by the project, and the company filed a 1099 for him in place of a W-2. The court held that he was an independent contractor, so the copyright in the program stayed with him.

Possession is a separate matter. Section 202 says that owning a copyright "is distinct from ownership of any material object in which the work is embodied". Holding the repository, the cloud account and the deploy keys gives you control of the code; the assignment gives you the right to it.

Who owns the code on day one depends on who typed it:

Geography adds a link to the chain. When the code is written by a foreign national and first published abroad, a US court may decide initial ownership under that country's law: in a 1998 case brought by the Itar-Tass news agency, the Second Circuit held that Russian law decided who owned articles created by Russian nationals and first published in Russia.

Only the owner of the rights, or its authorized agent, can sign a valid assignment of them (section 204), so ask for one signed assignment from an entity you can hold to it, plus its written confirmation that it holds signed IP agreements with everyone it puts on your code.

Ohio's standard terms show what a clean assignment looks like: they assign to the state all intellectual property that comes into existence through the vendor's custom work, while the vendor keeps its pre-existing tools, generic shells and subroutines as long as it licenses them to the state (page 39).

In the signed Florida contract we cite, the state owns all new intellectual property created in connection with the customer's contract, unless that contract says otherwise, and intellectual property developed before the term contract was signed stays outside that rule (section 12.5.1). Read the pre-existing materials clause twice: it decides which parts of your codebase stay the vendor's property, and a written license like Ohio's, perpetual and royalty-free to use and modify, is what lets you keep working on them (page 39).

The check differs by model:

• Staff augmentation: code lands in your repository every day, which feels like ownership and is possession. Ask for an assignment that covers work as it is created, and for the vendor's written confirmation that it holds signed agreements with every person it assigns to you, employees and subcontractors alike. Florida's contract requires every subcontract and staff arrangement to be in writing (section 4.3).
• Managed services: list in writing what transfers at exit, and when, before you sign: the application, and also the scripts, runbooks and tooling that run it. A provider can keep its own pre-existing tools and license them to you, the way Ohio's terms allow (page 39).
• Project outsourcing: check whether the assignment takes effect as the code is written, at delivery or on final payment, and what you hold if the project stops halfway.

This is why we contract as a US company: the IP assignment is handled US-side, under terms you can enforce.

How to pick in an afternoon

Three questions settle most of it.

Who will direct the engineers every day, and does that person have the hours? With an engineering lead who has the time and a roadmap that moves weekly, staff augmentation gives you the most control. If that role is still open, one of the other two models carries the plan for you.

Is the work a stable function you can measure the same way every month? Support, infrastructure and upkeep of a mature product fit managed services, because a service level can describe them.

Can you write the finish line on one page? Then project outsourcing gives you a price and a date, and your job becomes protecting the scope.

Run your own answers through the picker below. It returns the model that fits and the clauses to check for that model.

Then plan for the model to change. Deloitte's 2024 Global Outsourcing Survey of more than 500 executives found that 70% had selectively brought previously outsourced scope back in-house over the past five years, and that 80% planned to maintain or increase their investment in outsourcing. Buyers pull scope back in-house and keep outsourcing at the same time, so write the exit into the first contract: what transfers, who documents it, and how long the handover runs.

The hybrid we run: you direct, we back the developer

Here is where 2muchcoffee sits, so you can weigh this section knowing who wrote it. We work in three shapes, and they line up with the three models. A dedicated developer works full time on your product and is managed by you. A dedicated team of engineers, design and QA owns your product end to end, with one US company accountable for delivery. A project-based build fixes scope, price and timeline up front.

The dedicated developer is staff augmentation with the replacement row and the code row of that first table reinforced. You keep direction and priorities. Designers, QA, and code reviewers back every developer, so the second pair of eyes and the quality bar come from our side. If the fit is wrong, the developer is replaced fast, no extra cost. Capacity goes up or down in days, and the IP assignment sits with a US company.

It fits when you have product direction and someone to set priorities, and you want the vendor to carry quality and continuity. When you want someone else to own the outcome, the dedicated team or a project-based build is the better match, and we run both.

FAQ

What is staff augmentation? Staff augmentation is a contract in which a vendor supplies engineers who join your team and work under your direction, usually billed by time. You keep the plan, the priorities and the delivery risk. The vendor handles employment and payroll and finds replacements on the terms your contract sets.

What is the difference between staff augmentation and managed services? Direction and risk. With staff augmentation you direct the people and own the result. With managed services the vendor runs a defined function, such as support, operations or maintenance, and answers for it against a service level. In our experience, staff augmentation suits a roadmap that changes weekly, and managed services suit work you can measure the same way every month.

What is the difference between staff augmentation and project outsourcing? Staff augmentation buys capacity you direct. Project outsourcing buys a defined result: the vendor plans and delivers a scoped build. On a fixed price the vendor carries the risk inside that scope; on time and materials against an estimate, the overrun is yours. Changes to the scope come back to you as change requests.

Is a dedicated development team the same as staff augmentation? That depends on two answers: who sets the priorities and who answers for delivery. A dedicated team you manage day to day works like staff augmentation, and one that owns a product end to end works like managed delivery. Ask both before you sign, and you will know which model you are buying.

What is the difference between consulting and staff augmentation? Consulting sells judgment, usually tied to a deliverable the consultant stands behind: a recommendation, an architecture, a plan. Staff augmentation sells capacity your team directs. The line blurs in practice: a senior engineer can join your team and also challenge the plan.

Who owns the code written by augmented staff? Under US copyright law the author owns it first. As we read the statute, when the developer is the vendor's employee writing the code as part of the job, that author is the vendor; when the developer is an independent contractor, it is ordinarily the developer. Ownership moves to you through a written assignment signed by the owner, at every link of that chain. The repository on your account is possession, and the signed assignment is ownership. This is general information; have a lawyer read your contract.

One thing to check before you sign

Open the contract or proposal in front of you and tick each clause it already answers. The open items are the questions to settle, and the button copies them into a list you can send the vendor today.

If the shape you want is a senior developer you direct, with design, QA and code review behind them and the assignment signed by a US company, here is how we place a full stack developer inside your team.