Software development outsourcing
Software development outsourcing services
Software development outsourcing is four different arrangements wearing one name, and picking the wrong one costs more than picking the wrong country. This page explains the models, what the published rate tables leave out, and the cases where you should keep the work in house.
What is software development outsourcing?
Software development outsourcing is paying a company outside your business to build or maintain software for you, instead of hiring the people to do it internally. It covers four different arrangements, from a fixed scope project to individual engineers embedded in your own team, and choosing the wrong one costs more than choosing the wrong country.
The word is used loosely enough to be unhelpful. On the results page you have just come from, software development outsourcing variously means a fixed price project, a rented team, individual contractors, and a maintenance contract. Those are four different commercial relationships with different risks, and the first useful thing you can do is work out which one you are actually shopping for.
The second useful thing is to notice who writes about this. Every page ranking for this term is published by a company that sells outsourced hours, including this one. That shapes what gets written. You will find a great deal about how to choose a vendor and remarkably little about when not to hire one, which is the section further down this page.
What are the four outsourcing models?
Project outsourcing buys a defined outcome. A dedicated team buys a squad with its own lead pointed at your roadmap. Staff augmentation buys individual engineers inside your existing team. A managed service buys maintenance of something you already have. Most buyers ask for one and need another.
| Model | What you are buying | Right when | Wrong when |
|---|---|---|---|
| Project outsourcing | A defined outcome, a fixed scope and a price | The thing you want is describable now and will not change much. A migration, an integration, a replacement for one spreadsheet. | You cannot describe it precisely yet. Fixed scope on a vague brief becomes a change request argument in week three. |
| Dedicated team | A squad with its own lead, pointed at your roadmap | There is ongoing work to own but nobody free to run it day to day. You set priorities, the lead handles sequencing and review. | You only have six weeks of work. The ramp cost is not worth paying for a short engagement. |
| Staff augmentation | Individual engineers inside your existing team | You have a working team, a working process and a specific gap. Your leads review the code and own the architecture. | You have no technical leadership internally. Augmentation without someone to point it produces a lot of code and no product. |
| Managed service | Someone else runs and maintains a system you already have | The system works and you want it kept alive without hiring for it. | You need the system changed rather than maintained. Maintenance contracts are priced for stability. |
The most common mismatch is asking for staff augmentation when you need a dedicated team. Augmentation assumes you have technical leadership to point it, a review process and an architecture someone owns. If those are missing, adding engineers produces a lot of code that nobody is shaping, and the problem surfaces about four months in, when the thing works but cannot be changed.
The second most common is asking for a fixed price project for something nobody can describe yet. Fixed scope is a good structure for well understood work and a bad one for exploration, because every discovery becomes a negotiation. If you cannot write down what the software does in a page, you are not ready to fix the scope, and a vendor who agrees to fix it anyway has priced that risk into the number in front of you.
When should you not outsource software development?
Do not outsource when the software is how you compete and you intend to keep it, when nobody internally can answer questions day to day, when the work is exploratory and the specification does not exist yet, or when you are outsourcing to avoid a hiring decision you will still have to make in a year.
None of the nine pages ranking for this term has this section, which is understandable, because all nine are published by firms that would lose the sale. Here are the four cases where software development outsourcing is the wrong instrument.
The software is your competitive advantage and you intend to keep it. If the thing being built is the reason customers choose you, the knowledge of how it works is an asset you want inside the company. Outsource around it, not through the middle of it. Build the core internally and hire outside help for the parts that are not differentiating.
Nobody internal can answer questions. Every outsourced engagement consumes internal time: decisions, reviews, clarifications, access. If there is no one with a day a week to give, the engagement will stall and the invoices will not. This is the single most reliable predictor of a failed project, and it has nothing to do with the vendor.
The work is genuinely exploratory. When the requirement is "we think there is something here", the fastest loop is the shortest one, and a shorter loop beats a cheaper hour. Exploration across an eight hour time gap is slow in a way that no hourly rate compensates for.
You are deferring a hiring decision rather than making one. Outsourcing to delay building a team is a reasonable bridge and a poor destination. If the work is permanent, the cheapest version is eventually an employee, and the expensive version is three years of a bridge nobody revisited.
How much does software development outsourcing cost?
Published hourly rates range from roughly 25 dollars to over 200 depending on the region, and the figures on competing guides disagree with each other by a factor of four. The rate is also the wrong number to compare. What decides your cost is how many hours it takes to ship something that works.
Search this term and you will find a dozen rate tables. They do not agree. One guide puts onshore at 100 to 200 an hour and offshore at 25 to 50, another puts the same regions in noticeably different bands, and all of them are published by firms with an interest in where their own rate sits. We have deliberately not added a tenth table, because the honest position is that these numbers are marketing rather than measurement.
The comparison that actually decides your budget is cost per shipped feature, and it inverts the rate table more often than vendors admit. A senior engineer at 120 an hour who understands your business and ships in three days costs 2,880. A junior at 40 an hour who takes twelve days, two rounds of rework and four hours a week of your own senior's time costs more than that before you count the delay. The rate is visible on the invoice. The multiplier is not.
This is not an argument that expensive is always better, which would be its own kind of sales pitch. It is an argument that the rate is one input of several, and the others are the ones nobody tabulates: how fast they get to the first correct answer, how much of your own team's time they consume, how much rework comes back, and how much is left undocumented for you to pay for again later.
What are the hidden costs of outsourcing software development?
Five costs sit outside the hourly rate and routinely add a third or more to the real total: your own people's time, the ramp period, rework from misunderstood requirements, documentation that was skipped, and the cost of leaving. None of them appear in a quote and all of them appear in your year.
| Cost | Scale | What it actually is |
|---|---|---|
| Your own people's time | Significant, and almost never counted | Somebody internal answers questions, reviews work and makes decisions. On a team of four outsourced engineers this is routinely a day or more a week of a senior person. It is real money and it never appears in a quote. |
| Ramp | The first weeks produce little | Nobody is productive in an unfamiliar codebase and an unfamiliar business. This is paid at full rate and the only question is whether anyone planned for it. |
| Rework from misunderstanding | Varies wildly, and it is where cheap gets expensive | A requirement understood at eighty percent produces software that is wrong in a way nobody notices until a user finds it. The further the engineer is from the business, the more of this there is. |
| Handover and documentation | Usually skipped, always paid for later | If the work is not documented, you pay again the first time you change it without the original team. |
| The exit | Invisible until you need it | Code in a vendor repository, infrastructure in a vendor cloud account, a domain in a vendor registrar. Each one is small until the day you leave. |
The first row is the one worth planning for, because it is the one you can control. Before an engagement starts, name the person who will answer questions and agree how much of their week it takes. If the honest answer is that nobody has the time, that is useful information about whether to start at all, and it is far cheaper to learn now than in month three.
How much does the time zone difference actually matter?
The time zone gap matters as review cycles per week, not as hours of difference. Four or more overlapping hours gives you one or two exchanges a day, which most teams can work with. Under two hours of overlap you get roughly one exchange a day at best, so every misunderstanding costs a day instead of an hour.
| Arrangement | Typical overlap | What that means in practice |
|---|---|---|
| Same country | 6 to 8 hours | Several exchanges a day. A misunderstanding is caught the morning it happens. |
| Nearshore, 1 to 4 hours apart | 4 to 6 hours | One or two exchanges a day. Workable for most teams, and the usual sweet spot. |
| 5 to 7 hours apart | 2 to 3 hours | One exchange a day if both sides protect the window. Miss it and a question costs a day. |
| 8 or more hours apart | 0 to 1 hour | One exchange a day at best, often one every two days. Works when the work is well specified and independent. Punishing when it is exploratory. |
The reason this is worth converting into exchanges rather than hours is that the cost is not linear. Going from eight overlapping hours to five changes very little. Going from three to one changes everything, because below a certain point a question and its answer no longer fit in the same day, and work that depends on the answer waits.
This is also why the time gap matters far more for exploratory work than for well specified work. Building a defined integration across a nine hour gap is fine. Working out what the software should do across a nine hour gap is slow, expensive and frustrating for everyone, and no hourly rate makes up the difference.
What is the biggest risk when you outsource?
Losing the ability to change your own software. Everything else, a missed deadline, a bad hire on the vendor side, a cost overrun, is recoverable. A system nobody inside your company understands, with no documentation and code you do not hold, is a permanent dependency on whoever built it.
The failure is quiet. The project delivers, the software works, everybody is pleased, and eighteen months later a small change costs six weeks because the only people who understood it have moved to another client. By then the leverage has gone: the quote is whatever the vendor says it is, because the alternative is a rewrite.
Three things prevent it, and all three belong in the contract rather than in a conversation. Code in your repository from the first commit, not transferred at the end. Infrastructure and third party accounts in your name. Documentation of why decisions were made, not just what the functions do, because in three years the why is the part you will need.
There is a fourth, softer protection: insist that at least one person inside your company reviews what is being built, even if they cannot write it themselves. Someone who has watched the thing being made can brief the next team in an afternoon. Nobody can brief anyone from a repository they have never opened.
How do you choose an outsourcing partner?
Compare how they work rather than what they list. Every firm offers the same services and quotes a plausible rate, so the list is not a differentiator. Ask what they have talked a client out of, who specifically will be on your work, and what you own on the day you stop paying.
Ask what they recommended against. A firm that has never told a client to do less is a sales process. Ask for a recent example where they proposed something smaller than the client asked for, and listen to whether the story has specifics in it.
Ask who, by name, and for how long. Many firms sell with senior people and deliver with whoever is free. Ask who will be in the repository in month one and month five, how many other clients they carry, and what happens if that person leaves.
Ask for the project that went wrong. Not the case study. The engagement that changed shape halfway through, and what they did about it. How a firm behaves in the week it discovers the undocumented integration is the thing you are buying, and it is never in the portfolio.
Ask what you own on exit. Code, infrastructure, data, accounts, documentation. The answer should be immediate and it should be in the contract. Hesitation here predicts more than any technical question on your list.
Start with something small and real. A two week piece of genuine work tells you more than six weeks of evaluation. You learn how they ask questions, how they handle an ambiguous requirement, and whether their estimate survived contact with your codebase. That is worth paying for even if you then choose somebody else.
Why do companies outsource software development?
The stated reason is almost always cost. The real reasons are usually speed and access: work that needs to start before a hire could be made, or a skill the team needs for four months and not for four years. Cost is the reason given to a board, and it is the least reliable of the three.
Speed to start. Hiring a senior engineer in the United States takes a quarter from writing the role to the first useful commit, and that assumes the search goes well. A team can start in one to two weeks. When the thing being built has a date attached, that difference is the whole argument, and it holds regardless of the hourly rate.
A skill you need temporarily. Most companies need a data engineer, a mobile specialist or a security reviewer for a defined stretch and not permanently. Hiring for a four month need creates a twelve month problem. This is the cleanest case for outsourcing and the one that most reliably works out.
Capacity without a permanent commitment. A roadmap with more on it than the team can carry, where nobody is confident the extra demand is permanent. Renting the capacity while you find out is a reasonable bridge, as long as somebody revisits the decision rather than letting the bridge become the road.
And cost, which is more complicated than it looks. The hourly rate can be genuinely lower, particularly across regions. Whether the total is lower depends on the multiplier in the section above, and the companies that get the saving are the ones that specify work well, protect an overlap window and keep somebody internal close to it. The ones that treat a low rate as the entire strategy tend to pay the difference back in rework.
Is it cheaper to outsource or hire in house?
Over a year, an outsourced senior engineer and an employed one usually land closer than the hourly rates suggest, because employment costs are not the salary. Outsourcing wins clearly on short engagements and specialist skills. Hiring wins clearly when the work is permanent and the knowledge needs to stay.
The comparison most buyers run puts a contract rate next to a salary, which is not a comparison at all. An employee costs salary plus payroll taxes, benefits, equipment, software licences, recruitment fees amortised over their tenure, the hiring manager's time, and the weeks before they are productive. Depending on the role and the state, the real figure is meaningfully above the salary line, and it is the figure to compare against.
Then there are the things that do not appear on either side of a spreadsheet. An employee accrues knowledge of your business that stays when the project ends. An outsourced engineer accrues the same knowledge and takes it with them. For a four month integration that difference is worth nothing. For the system your operations run on, it is worth more than any rate gap.
So the decision is less about price than about duration and permanence. Short and specialist, outsource. Long and central, hire. The expensive mistake is the middle case left undecided for three years, where a bridge arrangement quietly becomes the permanent structure and nobody ever books the hire that would have been cheaper from month eight.
One practical note on comparing quotes. When you shortlist software outsourcing companies, ask each of them to price the same two week piece of real work rather than the whole programme. The spread on a small, specified job tells you more about how they estimate than a proposal for six months of unspecified capacity, and it costs a fraction to find out.
What should you outsource and what should you keep in house?
Outsource work that is well specified, self contained and temporary. Keep work that is how you compete, work where the judgement has to sit with someone accountable, and work nobody has defined yet. The test is not technical difficulty, it is whether the knowledge needs to stay in the building.
| The work | Usually | Why |
|---|---|---|
| The thing customers choose you for | Keep | The knowledge of how it works is the asset. Outsource around it rather than through the middle of it. |
| Integrations with systems you do not control | Outsource | Well specified, self contained, and someone who has done six of them will be faster than your team doing its first. |
| Internal tools replacing a spreadsheet | Either | Specify it tightly and outsourcing works well. Leave it vague and you will pay for the vagueness twice. |
| Anything on a regulated path | Keep the decisions, outsource the build | The compliance judgement has to sit with someone accountable inside the company, whatever the contract says. |
| Maintenance of a stable system | Outsource | Predictable, low variance work that is a poor use of an employee you are trying to retain. |
| The first version of a product nobody has defined | Keep, or sit in the room | Exploration needs the shortest possible loop between question and answer. |
The row that catches people is the last one. Outsourcing the first version of something nobody has defined feels efficient, because the internal team is busy and the external one is available. It is the most expensive way to discover a requirement, because every misunderstanding travels a full day before anyone notices it, and in the exploratory phase almost everything is a misunderstanding at first.
The regulated row is worth stating plainly too. You can outsource the building of software on a regulated path, and plenty of software outsourcing companies do that work competently. What cannot be outsourced is the judgement about whether the result meets the obligation, because an auditor will ask a person inside your company and a contract will not answer for them.
How do you run an outsourced team so it works?
Protect one overlap window, write requirements as examples rather than descriptions, review work weekly rather than at milestones, and keep one person internally who knows what is being built. Most failed engagements fail on these four operating habits rather than on the choice of vendor.
Protect the overlap window and put decisions in it. Whatever hours you share, treat them as the expensive resource they are. Questions that block work go first, status goes last or goes in writing. Teams that fill the window with a standing meeting and leave the blocking questions to email lose most of the benefit of having an overlap at all.
Write requirements as examples. A description of what software should do is read differently by two people. A worked example with real numbers is read the same way by both. For anything involving a calculation, a rule or an edge case, give the inputs and the expected output rather than a paragraph, and most of the misunderstanding disappears before it costs anything.
Review weekly, not at milestones. A milestone review finds a month of divergence at the point where fixing it is expensive. A weekly look at working software finds a week of it. The cadence matters more the further apart you are, because distance slows the correction as well as the work.
Keep one person who knows what is being built. Not a project manager tracking status, someone who understands the thing itself and can answer a question about intent. When that person exists, an engagement survives a change of engineers on either side. When they do not, the knowledge lives only in the vendor, which is the dependency this whole page is about avoiding.
Decide the exit before you need it. Agree at the start what handover looks like: what is documented, who has which accounts, how much notice ends the arrangement. Agreeing it while everyone is happy takes an afternoon. Agreeing it while someone is leaving takes a lawyer.
None of this is specific to working with an outside firm, which is rather the point. These are the habits of a team that ships, and distance simply makes the absence of them more expensive. A client who runs these four well gets good work out of an average vendor. A client who runs none of them will struggle with an excellent one.
What should be in the contract?
Five clauses decide whether you are a client or a hostage: ownership assigned as work is created, accounts in your name, a defined notice period, agreed handover deliverables, and the right to hire anyone on the team. Everything else is commercial detail you can negotiate later.
Ownership on creation, not on payment. Intellectual property should transfer as the work is written, in your repository. A clause assigning it on final payment means an invoice dispute is also a hostage situation.
Accounts in your name. Cloud billing, domains, certificates, third party services. Name them in the contract rather than assuming, because the quiet form of dependency is an account only the vendor can open.
A notice period you can live with. Thirty days is normal for ongoing capacity. What matters more is that it is symmetrical: if they can leave in thirty days, so can you, and a one sided clause tells you how the relationship is designed.
Handover deliverables, listed. Not "reasonable assistance", which means nothing when relations have soured. A list: documentation of decisions, environment setup instructions, credentials, and a named period of overlap with whoever takes over.
No clause preventing you from hiring the team. Many agreements include a fee or a bar on employing the engineers who worked on your product. If the arrangement succeeds and the work turns out to be permanent, hiring the person who already knows the system is the cheapest option available to you, and a contract that forbids it is protecting the vendor's revenue at your expense. Negotiate it out, or agree a fee you would actually be willing to pay.
How does Voliom structure a dedicated development team?
A squad with its own technical lead, pointed at your roadmap and reporting on outcomes rather than hours. The lead owns sequencing and review, so you are not managing individual engineers. Your repository from the first commit, US overlapping hours, and a two week paid trial before any longer commitment.
A lead, not a pool. You give the team priorities. The lead handles who does what, reviews the work before it reaches you, and is accountable for what ships. The failure mode we are avoiding is the one where a client ends up line managing four contractors in a different time zone, which is a full time job nobody agreed to take.
Overlapping hours, deliberately. Four or more hours of overlap with your working day, because that is the point where a question and its answer still fit in the same day. We would rather be the more expensive quote that ships than the cheaper one that waits.
Your repository, your accounts, from day one. Code assigned as it is written. Infrastructure in your cloud account. Every third party service in your name. If you decide after one phase to continue with your own team, that is a normal ending rather than a negotiation.
Two weeks first. A real piece of work, paid, before any longer arrangement. You find out how we handle an ambiguous requirement and whether our estimate survived your codebase, and we find out whether the engagement has an owner on your side. Both answers are cheaper to get in two weeks than in six months.
If what you actually need is one defined outcome rather than ongoing capacity, say so and we will quote it as a fixed scope project instead. If what you need is for someone to tell you whether the work should be outsourced at all, that conversation is free and it quite often ends with us recommending you hire.
FAQ
Common questions
What is software development outsourcing?
Software development outsourcing is paying a company outside your business to build or maintain software, rather than hiring the people internally. It covers four arrangements: a fixed scope project, a dedicated team with its own lead, individual engineers embedded in your team, and a managed service that maintains something you already have.
How much does it cost to outsource software development?
Published hourly rates run from roughly 25 dollars to over 200 depending on region, and competing guides disagree with each other by a factor of four. The rate is the wrong number to compare. What decides your total is hours to ship something that works, plus your own team's time, ramp, rework and documentation, which no quote includes.
What is the difference between a dedicated team and staff augmentation?
A dedicated team comes with its own technical lead who owns sequencing and review, so you set priorities rather than manage individuals. Staff augmentation places engineers inside your existing team, under your leads and your process. Augmentation needs internal technical leadership to point it; a dedicated team supplies its own.
When should you not outsource software development?
Do not outsource when the software is how you compete and you intend to keep that knowledge, when nobody internal has time to answer questions, when the work is exploratory and no specification exists, or when you are using it to defer a hiring decision you will still face next year.
How much does the time zone difference matter?
The time zone gap matters as review cycles rather than hours. Four or more overlapping hours gives one or two exchanges a day, which most teams handle. Under two hours you get about one exchange a day, so a misunderstanding costs a day rather than an hour. It matters far more for exploratory work than for well specified work.
What is the biggest risk of outsourcing software development?
Losing the ability to change your own software. Missed deadlines and overruns are recoverable. A working system that nobody inside your company understands, undocumented and in someone else's repository, is a permanent dependency on the firm that built it, and the next quote is whatever they say it is.
Do we own the code if we outsource development?
You should, from the first commit, in your repository, with infrastructure in your cloud account and third party services in your name. Ownership assigned as the work is created rather than transferred at the end, written into the contract rather than promised in a meeting.
Can you work alongside our in house developers?
Yes, and it is common. We work in your repository, follow your review process and join your stand up. Where you have technical leadership we fit under it. Where you do not, a dedicated team with its own lead is usually the better structure.
How do you start an outsourcing engagement without a big commitment?
Start with two weeks of real work, paid, before any longer arrangement. You learn how the team handles an ambiguous requirement and whether the estimate survived your codebase. It is worth doing even if you then choose a different firm, because what you learn transfers.
Keep exploring
Related services
- IT staff augmentationEngineers inside your existing team
- Custom software developmentA delivered outcome rather than capacity
- Application modernizationWhen the system already exists
- Systems integrationMaking existing systems agree
Let's talk
Tell us what you're building.
Get a free 30-minute strategy call. You'll leave with a clear plan, a realistic estimate and our honest opinion, whether or not you work with us.
- Email usmail@voliom.com