DEV Community: Masoud Gorgani

Staff augmentation vs outsourcing, managed services and consulting

Masoud Gorgani — Wed, 30 Sep 2026 15:16:36 +0000

These four arrangements get quoted against each other as though they were competing prices for the same thing. They are not. They differ in who directs the work and who carries the risk, and those two questions decide which one fits.

What is staff augmentation, and what are the alternatives?

Most of the confusion comes from suppliers using whichever term sounds best, so it is worth being plain about what each one means before comparing them. The benefits of staff augmentation and of the other three are not in dispute; which benefit you need is the whole question.

Staff augmentation — You hire people, not an outcome. Engineers join your team, work to your priorities, use your tools and report to your managers. The supplier handles employment, payroll and replacement. Also called team augmentation, resource augmentation or IT staffing.
Outsourcing a project — You pay for an outcome, not people. The supplier takes a defined scope, staffs it themselves, and is accountable for delivering it. You review the result rather than directing the work day to day.
Managed services — You pay for an ongoing service level rather than either. The supplier runs and maintains something — an application, a platform, a support desk — against agreed response times, and decides for themselves how many people that takes.
Consulting — You pay for judgement. Someone assesses a situation and tells you what to do about it. Some consultancies then offer to do it; the advice and the delivery are separate engagements, and it is worth knowing which one you are being offered.

The difference that actually decides it

Strip away the labels and two questions separate these arrangements. Who directs the work, and who carries the risk if it goes wrong.

With staff augmentation you direct the work and you carry the delivery risk. The supplier guarantees that a competent person turns up; they do not guarantee that the thing gets built, because they are not deciding what gets built. If the roadmap is wrong, that is yours.

With outsourcing the supplier takes both. They decide how to staff and sequence the work, and they are on the hook for the result. That is why outsourcing contracts have detailed scopes: the scope is the thing being guaranteed, so both sides need it written down.

Neither is safer than the other. They put the risk in different places, and the right answer depends on which risk your company is better equipped to carry.

Staff augmentation vs outsourcing

This is the comparison people ask for most, and the honest answer is that it turns on how well you can specify the work.

If you can write down what needs building in enough detail to hold someone to it, outsourcing transfers real risk and is usually worth it. If you cannot — because the product is still being discovered, or the requirements change monthly — a fixed scope becomes a change-request argument, and staff augmentation avoids that by not pretending the scope is stable.

The second factor is whether you have someone to direct the work. Staff augmentation assumes you do. If nobody on your side has the time or the technical standing to set priorities and make decisions, augmented engineers will wait, and you will pay for the waiting.

Cost usually favours outsourcing on paper and staff augmentation in practice, for the same reason: the outsourced price covers the scope as specified, and most scopes change.

Staff augmentation vs managed services

Managed services are not a third way of building something. They are a way of running something that already exists.

The contract is written around availability and response rather than output — an hour to acknowledge a critical incident, a day to resolve it, a monthly allowance for changes. You stop paying for people and start paying for a guarantee.

That is good value when the work is genuinely continuous and unpredictable, which is what application support usually is. It is poor value when the work is a project with an end, because you end up paying an availability premium for capacity you could have hired directly.

Staff augmentation vs consulting

Consulting is the answer when the problem is a decision, not a shortage of hands. What to build, whether to rebuild, which platform, whether the supplier you already have is doing a competent job.

The trap is paying for consulting when you actually needed capacity. A strategy document does not build anything, and a team that already knew what to do does not need one. The reverse trap is just as common: hiring engineers to build something nobody has established is worth building.

A useful test is whether you could brief the work today. If yes, you need capacity. If the honest answer is that you would be guessing, the cheapest step you can take is a few weeks of someone working out what the answer is.

Which one fits your situation

Choose staff augmentation when — You know what to build, you have people who understand the business, and there are not enough of them. You have someone able to direct the work, and the requirements will keep moving.
Choose project outsourcing when — The scope can be written down and held still, you have no one available to manage engineers day to day, and you would rather pay for a delivered result than a team.
Choose managed services when — The software already exists and someone has to keep it running. The work is unpredictable in timing but continuous in nature, and downtime has a cost you can put a number on.
Choose consulting when — You cannot yet brief the work. The decision is the problem — what to build, whether to rebuild, or whether the current approach is sound.

What goes wrong with each

Staff augmentation fails when nobody on the client side is directing the work. Engineers arrive, wait for decisions, and become expensive. It also fails when a supplier rotates people between clients and calls it a dedicated team: you pay the onboarding cost repeatedly and never accumulate anyone who knows your system.

Outsourcing fails when the scope was a guess. Every discovered requirement becomes a commercial negotiation, the relationship turns adversarial, and both sides start optimising for the contract rather than the software.

Managed services fail when the service level was written for a different kind of software than the one you have. A four-hour response is meaningless if the failure mode is silent data corruption nobody notices for a week.

Consulting fails when the advice is not accountable to delivery. Recommendations from people who will not have to live with them tend towards the ambitious.

You can combine them, and most companies do

These are not exclusive. A common and sensible sequence is a short piece of consulting to decide what to build, a dedicated team or augmented engineers to build it, and a support arrangement once it is live.

What matters is being clear which one you are paying for at any given moment, because the thing being guaranteed is different in each. Confusion about that is the single most common reason these arrangements disappoint.

Originally published on the Cognivise blog.

How to choose a software development company, and what to check first

Masoud Gorgani — Wed, 30 Sep 2026 15:16:18 +0000

Almost every supplier will show you a portfolio and a process diagram. Neither predicts how the engagement goes. These are the things that do, and most of them can be checked before you sign anything.

Start with the question you actually need answered

Before comparing suppliers, be clear about which of three things you need, because they are arranged differently. A defined piece of work with a shape you can describe. Capacity, because you know what to build and have too few people. Or a decision, because you are not yet sure what is worth building at all.

A supplier who is good at one is not automatically good at the others. Asking a delivery-focused firm to tell you what to build, or a consultancy to staff a team, produces a bad fit that neither side notices until the invoices start.

What a shortlist should actually test

A portfolio shows what shipped. It does not show what it cost, how long it took, how much of it was rewritten in the first year, or whether the people who built it still work there. So test the things that do predict the outcome.

Directory rankings are worth less than they look. A list of the top software development companies is usually ordered by who paid, reviewed, or submitted a profile — useful for finding candidates, useless for ranking them. Treat it as a source of names and do your own comparison.

Who specifically will do the work — Not the company's average experience: the named people on your engagement. Ask what else they are on, and what happens if one of them leaves mid-project. If the answer is vague, you are being offered one team and delivered a different one.
Whether they will tell you no — Describe something slightly wrong on purpose — a feature that does not fit, a deadline that is not realistic. A supplier who agrees to everything in the sales conversation will agree to everything in delivery too, and that is how scope quietly becomes your problem.
What happens after launch — Ask who maintains it, on what terms, and what it costs. A quote that ends at launch is not a quote for working software. Support is either priced now or negotiated later from a weak position.
Who owns the code — It should be you, in your own accounts, from the start rather than at the end. If ownership transfers only on final payment, or the supplier keeps parts of it as their framework, you are renting.

Software development pricing models, and what each one hides

Most quotes come in one of three shapes. None is dishonest; each moves risk to a different place, and knowing which is the point.

Before comparing them, be wary of anyone who answers “how much does custom software cost” with a number before asking what it has to do. Custom software development cost is a function of scope, integration and how much is still unknown, and a figure quoted without those is a sales tactic rather than an estimate.

Fixed price — You pay an agreed amount for an agreed scope. The supplier carries the risk of it taking longer, and prices that risk into the number. Works when the scope genuinely can be held still. When it cannot, every discovery becomes a change request and the relationship turns adversarial.
Time and materials — You pay for the hours worked. You carry the overrun risk, and in exchange you can change direction without renegotiating. Fixed price vs time and materials is really a question about how well you can specify the work, not about which is cheaper.
A capped or staged budget — Time and materials with a ceiling, or a series of small fixed pieces. Usually the most honest arrangement for work that is partly unknown, because it keeps both the flexibility and a number you can plan around.

What the software development contract has to say

The contract matters most in the situations nobody expects when signing it. Four clauses do the work.

Ownership of the source code, the documentation and the accounts, stated as transferring during the engagement rather than at the end. Test it by asking for repository access on day one.

What happens when scope changes — who decides, how it is priced, and whether work pauses while that is agreed. This is the clause that decides whether a discovery is a conversation or a dispute.

Exit. How much notice, what gets handed over, and in what state. A supplier confident in their work makes leaving easy, because they do not expect you to want to.

Support after launch: response times, what counts as a defect rather than a change, and what it costs. Agree it before launch, when you still have leverage.

Signals that a supplier will be expensive in ways the quote does not show

A quote far below the others is not a bargain. It usually means a different scope was understood, or that the gap will be recovered through change requests. Ask what they assumed, and compare assumptions rather than totals.

A proposal that arrives immediately, without questions, describes a generic project rather than yours. Good software development proposals are slower because they involve someone actually thinking about your situation.

Being unable to name a project that went badly. Everyone has one. A supplier who cannot describe what went wrong and what they changed has either not been doing it long or is not being straight with you.

Talking only about technology. The stack matters far less than whether they understood the business problem, and a conversation that never leaves the tooling is usually hiding that they did not.

Questions worth asking every supplier

What would you need from us to make this work? — Every engagement depends on the client for something — decisions, access, a person who can answer questions. A supplier who says they need nothing has not thought about it, and you will find out which things they needed when they are late.
What is the first thing you would build? — The answer shows whether they think in terms of risk or in terms of features. The first thing should usually be the part you are least certain about.
How will we know it is going badly? — Ask for the specific signal and when you would see it. “Weekly demos” is an answer. “Good communication” is not.
What would make you turn this down? — It tests whether they have a view at all. A supplier with no conditions will take anything, which tells you what their judgement is worth on your project.

When the answer is not to hire a company at all

Sometimes the honest recommendation is an off-the-shelf product with some configuration, and a good supplier will say so. Custom software earns its cost when the process is genuinely yours, when the integration is the point, or when the thing you need does not exist. Not when an existing tool almost fits and nobody has tried it properly.

And if the need is continuous rather than a project, hiring your own engineers is usually cheaper over a few years than any supplier, whatever the day rate comparison says. The reason to use a company is speed, specific expertise, or not wanting to carry the hiring risk — all legitimate, and all worth being explicit about.

Originally published on the Cognivise blog.