Search for outsourcing product development, or its older name, outsourcing software development, and most of what comes back is written by development shops ranking themselves, or by lists of countries sorted by hourly rate. Both treat the decision as a question of where the developers sit and what they charge per hour.
That matters, but it is the second question. The first is what you are actually buying. Every outsourcing arrangement sells one of four units: an hour, a project, a seat on a team, or a place in a queue. The unit decides who pays when the spec turns out to be wrong, and on a first version of anything, the spec is always partly wrong.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
The Short Answer
If you only read one section, read this one.
- A small, well-defined job: a freelancer, by the hour or by milestone.
- A defined project with a hard budget and a fixed scope: an agency on a fixed price, knowing the quote includes a buffer for what nobody can see yet.
- A long roadmap, and someone in-house who manages engineers: a dedicated team or staff augmentation.
- A steady stream of product work, no engineering manager, and a budget well under a senior hire: a product development subscription.
- You need technical decisions more than code: a fractional CTO, alongside one of the above.
The rest of this guide explains why, starting with what a hire would cost you, because that is the number every option is really competing with.
What Outsourcing Product Development Means
Outsourcing product development, also called outsourcing software development, means paying people outside your company to design, build or maintain your software product, instead of employing them. It is really two decisions that most guides blur into one.
Where the people are. Onshore means your own country, nearshore means a nearby one with similar working hours, and offshore means a distant one, often with little overlap in the working day. Location mostly sets the rate and the time zone gap.
What you buy. An hour of someone's time, a finished project, a person's full working month, or a place in a queue of work. This mostly sets who carries the risk, and it is the choice that decides whether the arrangement works.
A cheap hourly rate in the wrong unit is still expensive. A high rate in the right unit can be the cheapest option you have.
The Benchmark: What a Hire Costs
Every outsourcing option is priced, whether it says so or not, against the cost of employing a developer yourself.
The salary is also only the part you can see. Recruiting a senior engineer takes months, the first few of which are spent learning your product, and the role needs someone to set priorities and review the work. For a company with a full-time roadmap and an engineering manager, a hire is often the right answer. For everyone else, the question is which outsourcing unit gets closest to a senior developer's output without paying for a whole one.
The Six Ways to Outsource Product Development
1. Freelancers
Individual developers you hire directly or through a marketplace. On Upwork, hourly contracts are billed on the hours logged each week, and fixed-price contracts are paid by milestones that you fund into escrow before work begins. The client pays a marketplace fee on every payment, plus a small fee to start each new contract. You manage the work, you write the spec, and on hourly contracts every change is more hours on your bill. Freelancers are a good fit for small, well-defined jobs and a poor one for a product that needs years of continuity, because the person who knows your codebase can take other work or leave the platform.
2. Vetted talent networks
Services that screen developers and match you with one, so you skip the filtering that makes marketplaces slow. Toptal says it accepts fewer than 3 percent of the more than 200,000 people who apply each year, usually introduces candidates within 24 hours, and starts each engagement with a trial of up to two weeks that you are not billed for if you are not satisfied. Arc advertises hourly pay for freelance contracts, and Lemon.io says you pay only for the work delivered. The unit is still the hour, so the cost of change still sits with you, and you still need to direct the work day to day. You are paying for the screening, not for a different risk model.
3. Agencies and development shops
A firm takes a defined project and delivers it, usually for a fixed price agreed after a discovery phase. You get a team, a project manager and a single invoice. The catch is structural: a fixed quote has to cover everything the agency cannot yet see, so it includes a buffer, and anything outside the written scope becomes a change order. This works best when the scope really can be written down in advance, which is rare for a first version.
4. Offshore and nearshore dedicated teams
A vendor, usually abroad, assigns developers who work only on your product, billed per person per month. You buy capacity, not outcomes. It can be the cheapest way to get a lot of engineering hours, and it can work well with strong direction from your side. Without that direction, a dedicated team will stay busy and still build the wrong thing.
5. Staff augmentation
Contract developers join your existing team, use your tools and processes, and report to your engineering lead. It is the same seat-based unit as a dedicated team, without the separate vendor structure around it. It only works if you already have the engineering management it plugs into.
6. Product development subscriptions
A flat monthly fee for a queue of requests, worked one at a time, usually by a senior developer, with the freedom to pause or cancel between months. The price does not move when the plan changes. A changed or wrong request goes back into the queue, so the cost of being wrong is time rather than money. It fits steady product work without an engineering manager, and it does not fit work that needs several developers in parallel.
Who Pays When the Spec Is Wrong
This is the question that separates the six models, and almost no pricing page answers it.
Software specs change because building something is how you find out what it should have been. A screen that looked right in a mockup is confusing in use. A customer asks for a field nobody planned. An integration turns out to return data in a shape nobody expected. None of this is a failure of planning. It is what building a first version is like.
Each unit handles that differently.
An hour. You pay for every change as more hours. The price is honest, the total is unknown, and the risk is entirely yours.
A project. The vendor prices the unknown into the quote up front, then charges change orders for anything outside the written scope. You pay for the risk twice, once as a premium you cannot see and once as extra invoices you can.
A seat. You pay for a person's month whether their work that month was right or wrong. The cost is predictable. The output depends on how well you direct it.
A place in a queue. The price is flat. A change becomes another request, and a wrong result becomes a revision. You pay for being wrong in calendar time, not in money, which is usually the currency a small company can better afford.
Location decides the rate. The unit decides who pays for the surprises, and on a first version there are always surprises.
None of these is best in general. If your scope really is fixed, the project unit is fine and the buffer buys certainty. If you have an engineering manager, seats are efficient. The mistake is choosing on rate alone and discovering the risk model after the first change request.
Six Models Side by Side
| Model | What you buy | Who directs the work | Who pays when the spec changes | Best fit |
|---|---|---|---|---|
| Freelancer | Hours or milestones | You | You, in hours | Small, well-defined jobs |
| Vetted talent network | Hours | You | You, in hours | A skilled individual, quickly |
| Agency or dev shop | A fixed-scope project | The agency | You, twice: buffer then change orders | Fully specified projects |
| Offshore or nearshore team | Seats, per person per month | You | You, in seats | Large roadmaps with strong direction |
| Staff augmentation | Seats on your own team | Your engineering lead | You, in seats | Teams that need more hands |
| Product development subscription | A place in a queue | You set priorities, the developer plans the work | Nobody pays more, it costs time | Steady product work, no engineering manager |
Onshore, Nearshore or Offshore
Once you know the unit, location is mostly a trade between rate and overlap.
Offshore teams usually cost the least per hour. The price is the time zone: a question asked in your afternoon can wait until your next morning for an answer, and on early work, where questions come daily, that gap compounds. Nearshore teams share more of your day at a higher rate. Onshore costs the most and removes the gap entirely.
The rule of thumb is simple. The less settled the spec, the more overlap you need. A well-specified maintenance job can run happily twelve hours away. A first version usually cannot.
The Risk Nobody Prices: Who Owns the Code
This is the part of outsourcing that is easiest to skip and most expensive to get wrong.
Under US copyright law, the person who creates a work is ordinarily its author. The Copyright Office's Circular 30, Works Made for Hire, describes the two exceptions. Work prepared by an employee within the scope of the job belongs to the employer. Work that is specially ordered or commissioned counts as made for hire only if it falls into one of nine categories, such as a contribution to a collective work, a translation, a compilation or a test, and both parties sign a written agreement saying so. In the circular's words, if a work fails to satisfy any of these requirements, "it is not a work made for hire."
Software is not one of the nine categories. Our reading is that code an independent contractor writes for you does not become yours just because you paid for it, and needs a written assignment of copyright in the contract. Whether someone is an employee or a contractor is also not settled by what the contract calls them. The circular says it turns on the general common law of agency, weighing factors such as who provides the tools, how the person is paid and whether they receive employee benefits. None of this is legal advice, and a lawyer should read the contract before you sign it.
The practical protection costs nothing and takes an afternoon.
Before any code is written
- The contract contains a written assignment of all intellectual property in the work to your company, signed by the developer or vendor.
- The code lives in a repository in your own account (GitHub, GitLab or similar) from the first commit, with the developer invited as a collaborator.
- Hosting, domains, databases and any app accounts are registered to your company, not to the developer.
- Passwords and API keys are stored somewhere you control, and you can revoke the developer's access in one step.
- You can run the project yourself from the repository's instructions, or someone you trust has checked that it can be.
A vendor who resists any of these is telling you something important about the end of the relationship.
Want software built without hiring or quoting projects?
A senior developer on subscription: $849 a month, as many requests as you like, most shipped within 48 to 72 hours, and your money back if the first 7 days don’t prove it.
How to Outsource Product Development
- 1
Write down the problem, not the solution
Describe who has the problem, what they do today and what should change. A list of screens is a guess at the answer. A clear problem lets a good developer suggest something simpler than what you would have specified.
- 2
Decide how settled the spec really is
If you could hand over a complete spec today and it would not change, a fixed-price project is reasonable. If you expect to learn as you go, choose a unit where change is cheap: hours if you can manage them, a queue if you cannot.
- 3
Decide who will direct the work
Seats and hours need someone on your side who can set priorities and review technical work. If that person does not exist, choose a model where the vendor plans the work, or add a fractional CTO.
- 4
Own the repository and accounts before the first line of code
Everything on the checklist above, done before work starts, not negotiated at the end.
- 5
Start with one small, real piece of work
Not a test project invented for the purpose, but the first real thing you need. How a developer handles a small real task, including the questions they ask, predicts the large ones better than any interview.
- 6
Insist on working software on a schedule
A demo you can click, every week or every delivered request. Status reports describe progress. Working software proves it.
- 7
Plan the exit on the first day
Short written notes on how to run, deploy and change the project, kept up to date as you go. The best outsourcing relationships are the ones you could end next month without losing anything.
Which Model to Pick
A landing page, a script, a single integration with a written spec. Pay by milestone if you can, keep the code in your repository, and do not build a long-lived product on one person you found last week.
Accept that the quote includes a buffer, and read the change-order terms before you sign. If you already expect to change your mind, this is the most expensive way to do it.
The cheapest way to buy a lot of engineering capacity, as long as someone on your side is directing it every day.
A flat price for a queue of requests, so changes and revisions cost time rather than money, and you can pause between months. Not for work that needs several developers at once, and not a substitute for a full team.
If you have a full-time roadmap and someone to manage engineers, employing a developer usually becomes the cheapest option over time. Outsourcing is how you get there without hiring before you are sure.
Where a Product Development Subscription Fits, and Where It Doesn't
We run a product development subscription, so read this section with that in mind.
It works well for a company with a real product and a steady list of things to build or fix, and no engineering manager to direct contractors. You add requests, they are worked one at a time by a senior developer, and the price stays flat whatever the list contains. It removes the two costs that hurt small companies most in the other models: paying extra every time the plan changes, and paying for a seat that needs daily direction.
It is the wrong choice in some cases, and we would rather say so here. It does not suit a large build that needs several developers in parallel to hit a date. We do not build native mobile apps. And if your work is truly full-time for the foreseeable future, a hire, or a dedicated team with a lead, will eventually cost less.
The Bottom Line
Most outsourcing advice starts with the map: which country, which rate. Start with the unit instead. Decide how settled your spec really is and who on your side can direct the work, and the right model usually becomes obvious. Then choose the location by how much of the working day you need to share.
Whatever you choose, own the repository, the accounts and the rights before the first line of code. Every model on this page can work well. The ones that end badly usually fail on that checklist, not on the rate.
