Outsourcing of Software Development: A Buyer's Guide

Outsourcing of software development means paying an external company to design, build, test or maintain software that you would otherwise staff yourself. It works when you keep the decisions (what to build, what counts as done, who owns the code and the accounts) and hand over execution that can be clearly described. It goes badly when a company tries to outsource the thinking as well. This guide covers what to outsource, how to choose and contract a partner, and how to run the work week to week.

A plain disclosure: Yarqat is an offshore engineering company based in Pakistan, so I sell what this guide describes. Read it with that in mind. I have included the cases where outsourcing is the wrong answer, because a client who should never have outsourced ends up unhappy whoever they hire.

Where the outsourcing of software development fits in information technology outsourcing

Information technology outsourcing is the broad category: handing any IT function to an outside provider. That includes hosting and infrastructure, help desk, security monitoring, application support and software development. Development is one part of it, and it behaves differently from the rest.

Infrastructure and support can be bought against service levels, because the work is repeatable and you can define "good" in advance. Software development is bought against requirements that are still being discovered while the work is under way. Buyers who treat it as a commodity, and choose on price the way they would choose a hosting provider, tend to get exactly what they specified and nothing they needed.

What to outsource and what to keep

The useful split is between decisions and execution. Keep the first. You can outsource a great deal of the second.

Area	Keep or outsource	Why
Product direction and priorities	Keep	Nobody outside your business can decide what matters most to it.
Customer and domain knowledge	Keep	A partner can learn your domain, but the source of truth has to be inside.
Sign-off on architecture	Keep	A partner can propose it. Someone answerable to you should approve choices you will live with for years.
Repositories, cloud accounts, domains, app store accounts	Keep, always	If these are in the supplier's name, you do not control your own product.
Acceptance of finished work	Keep	The party that builds should not be the only party that decides it is done.
Building features against clear requirements	Outsource	This is the bulk of the work and the part that transfers best.
Specialist skills you need briefly	Outsource	Mobile, data engineering, DevOps or security testing rarely justify a permanent hire for a short need.
Testing, maintenance and support of stable systems	Outsource	Well-defined, continuous, and easy to measure.

If you have no technical person at all, the architecture row is the one that hurts. Hire an independent adviser or a part-time technical lead to hold it, separate from the company doing the build.

Product development outsourcing: can you hand over a whole product?

Yes, and many companies without an engineering team do so for a first version. Product development outsourcing works on three conditions. Someone inside your business acts as product owner and makes decisions daily. The work begins with a short discovery phase, so that the scope is written down before it is priced. And you decide in advance where the knowledge goes after launch: a long-term arrangement with the same partner, or a planned handover to a team you hire.

Engagement models for an outsourced development team

There are four common ways to structure the relationship. Each is covered in depth on its own comparison page, so this table is only the summary. A dedicated team that stays with you for years is a model of its own, covered in what an offshore development center is.

Model	What you pay for	Fits when	Watch for
Fixed-price project	An agreed scope for an agreed price	The work is well specified, stable, and has an end	Every change becomes a negotiation
Time and materials	The time actually spent, usually billed monthly	The scope will evolve as you learn	Needs your active steering and a budget ceiling
Dedicated team	A stable team reserved for you	You have a long roadmap	You must keep the team supplied with priorities
Staff augmentation	Individuals who join your existing team	You have a team and a specific gap	You manage them, and you carry the delivery risk

For the detail, see fixed price versus time and materials on the commercial side, and staff augmentation versus a dedicated team on the staffing side. If you have not yet decided whether to outsource at all, start with in-house versus outsourced development. Where the partner should be located is a separate question, covered in offshore versus nearshore versus onshore.

How to choose and vet a partner

Portfolios and sales decks all look alike. These checks tell you more.

1. Speak to the engineers who would do the work. Not only the salesperson or the founder. Ask who, by name, will be on your project, and talk to them.
2. Look at how they work, not only what they have shipped. Ask them to walk you through how a change goes from ticket to production: code review, automated tests, deployment, monitoring. Vague answers here predict vague delivery.
3. Call references yourself. Ask what went wrong on the project and how the supplier behaved when it did. Every project has something go wrong, so a reference with no answer is not much of a reference.
4. Notice how they treat your brief. A good partner questions the scope, points out what is missing and says no to some things. A supplier that agrees with everything and quotes a fixed price for a vague brief within a day is telling you how the project will go.
5. Check who you are actually contracting with. A registered company, a named signatory, and a size that suits your project. Too large and you are a small account. Too small and one resignation stops your work. The comparison of a freelancer versus an agency covers that trade-off.
6. Start with a small paid piece of work. A discovery phase or one real feature, over a few weeks. You learn more from a fortnight of working together than from any number of meetings.

If nobody on your side can judge the technical answers, borrow someone who can. The checks in technical due diligence apply just as well to a supplier's work as to an acquisition.

Contracts and IP

I am not a lawyer, and you should have one review any agreement. These are the points I would want settled before work starts.

• Intellectual property assignment. In many jurisdictions, including the United States and the United Kingdom, code written by a contractor does not become yours simply because you paid for it. The contract needs an explicit written assignment, covering the supplier's employees and any subcontractors, and it should say when ownership passes.
• Pre-existing and open-source code. If the supplier uses its own libraries, you need a permanent licence to keep using them. Open-source components and their licences should be disclosed.
• Accounts and access. Repositories, cloud accounts and deployment pipelines are created in your name from the first day, with the supplier given access, not the other way round.
• Confidentiality and data protection. A confidentiality agreement as standard. If personal data is involved, a data processing agreement, and where laws such as the GDPR apply, a lawful mechanism for transferring data across borders.
• Acceptance and warranty. What counts as done, who decides, and how long the supplier fixes defects at its own cost.
• Termination and handover. Notice periods on both sides and a duty to hand over code, documentation and credentials when the contract ends, whatever the reason.
• Subcontracting. Not without your written consent.
• Governing law and disputes. Agree them explicitly, and be realistic: enforcing a contract across borders is slow and costly.

That last point is why practical protection matters more than clever drafting. If the code is in your repository, the accounts are yours and you pay monthly or by milestone, the most you can lose in a dispute is a few weeks of work.

Managing outsourced software development week to week

Most outsourced projects that fail were not badly built so much as badly steered. A simple, boring rhythm prevents most of it.

• Start of the week: agree a short, ordered list of priorities, each with a sentence describing what "done" means.
• Every day: a brief written update from the team (done, next, blocked) and same-day answers from you. Your response time sets the team's speed more than anything they control.
• Midweek: look at work in progress on a staging environment. Catching a misunderstanding on Wednesday is far cheaper than catching it at the demo.
• End of the week: a demo of working software, not slides or status percentages.
• Once a week: compare spend against budget and progress against plan, and say out loud if they are drifting apart.
• Once a month: a retrospective with the team, and a look at the code by someone technical who answers to you.

Three things should be true at all times. Code is merged into your repository continuously, not delivered in one bundle at the end. There is an environment where you can try the current state of the product yourself. And there is one named person on each side who can make a decision.

The failure modes

• Outsourcing the thinking. The supplier is left to guess what the business needs, guesses reasonably, and is wrong.
• A fixed price on a vague scope. Both sides spend the project arguing about what was included.
• The absent client. Questions wait days for answers, the team fills the gaps with assumptions, and the result surprises everyone.
• Choosing on the day rate. The cheapest rate and the cheapest finished product are different things, because rework is billed too.
• Bait and switch. Senior people win the work and junior people do it. Name the team in the contract.
• The big reveal. Nothing visible for months, then a delivery that does not match what you pictured.
• No exit plan. All the knowledge sits with the supplier, and leaving means starting again.

When not to outsource

• You do not yet know what the product is. If requirements change daily because you are still discovering the idea, pay for discovery first, not for a build team.
• The software is your core advantage and you will build on it for years. Outsourcing can start it, but plan to grow the capability in-house.
• Nobody inside has time to be the product owner. No supplier can make up for that.
• The work is legally restricted. Clearance requirements or rules on where data is processed and by whom may rule out some or all suppliers.
• You are trying to fix an internal problem. If your own team cannot ship because priorities are chaotic, an outside team will inherit the chaos and add a time difference.
• An existing product would do the job. Buying is usually cheaper than building, by anyone.

Frequently asked questions

What is an outsourced development team?

An outsourced development team is a group of engineers, usually with a lead and often with QA and design, employed by an external company and assigned to your work. It may deliver one project or stay with you long term as a dedicated team. You direct what it builds. The supplier is responsible for employing, equipping and managing the people.

What is the difference between information technology outsourcing and software development outsourcing?

Information technology outsourcing covers any IT function run by an outside provider, including infrastructure, support and security operations. Software development outsourcing is the part concerned with building and maintaining software. It needs closer day-to-day collaboration than the others, because the requirements change as the work proceeds.

What kinds of companies outsource software development?

Companies that outsource range from founders with no technical team, to established businesses that need a system built but do not want a permanent engineering department, to large technology firms adding capacity or specialist skills. I have left out the usual list of famous names, because most versions of it are repeated without sources.

Is product development outsourcing a good idea for a startup?

It can be, for a first version, if a founder acts as product owner and the company owns the code and accounts from the start. It is a poor fit when the idea is still changing daily, or when the founders expect the supplier to make product decisions for them.

What is the hardest part of managing outsourced software development?

Staying involved. The temptation is to hand over a brief and wait. The projects that go well have a client who answers questions the same day, reviews working software every week and makes decisions quickly.

If you are considering this route, our software outsourcing page explains how we structure ownership, scope and handover.