Software Development Outsourcing Models: A Map for US Companies

Three questions, not one list

Every outsourcing arrangement answers three questions. Mixing them up is the source of most confused proposals we see.

1. Relationship: who manages the work? You, the vendor, or something in between. This determines control, accountability and how much of your own management time the engagement needs.
2. Pricing: how do you pay? For a result, for time, for a team per month, or for an outcome. This determines who carries cost risk.
3. Location: where does the team sit? Onshore, nearshore or offshore. This determines rates and, more importantly for US companies, how many working hours you share.

The choices are partly independent. A dedicated team can be in Poland or in Colombia; a fixed-price project can go to a vendor in Ohio or in India. But they aren't fully independent: some relationship and pricing combinations work naturally, and some contradict themselves. The diagram below shows which.

Axis 1: relationship models

Sorted from "you manage everything" to "the vendor manages everything", with two models at the end for companies that want a lasting presence abroad.

Staff augmentation

Individual engineers join your team and work inside your process. You set priorities, review code and own delivery; the vendor recruits, employs and replaces. It's the fastest way to add capacity when you already have engineering leadership. The variants (short-term, skill-based, long-term) are covered in types of staff augmentation.

Dedicated team

A complete, self-organizing team (developers, often QA, a team lead, part-time design or DevOps) works only on your product. You own the backlog; the team owns how it delivers. It fits products that will change for a year or more. We compare it with its neighbors in dedicated team vs staff augmentation and dedicated team vs project-based outsourcing.

Managed services

The vendor owns an outcome under a service-level agreement: "the platform stays up, security patches within 7 days, two feature releases a month". You manage the vendor, not the people. It suits mature products where the work is predictable. Moving from augmentation to this model is a common path, described in staff augmentation to managed services.

Project-based outsourcing

The vendor delivers a defined scope by a date, usually for a fixed price, and carries the delivery risk inside that scope. Ideal for bounded work with stable requirements; expensive when the scope moves.

Offshore development center (ODC)

A larger, long-term unit (typically 15–50+ engineers) run by the vendor as your engineering hub abroad, often with its own management layer and sometimes its own office space. Think of it as a dedicated team grown into a department. It makes sense once you need dozens of engineers for years. The comparison with augmentation is in offshore development center vs staff augmentation.

Build-operate-transfer (BOT)

The vendor builds a team in its country, runs it for 18–36 months and then transfers people and processes to your own local entity for a pre-agreed fee. You get a captive center without learning local hiring, payroll and labor law from scratch. It's the most expensive path in management attention and only pays off at a scale of roughly 20 people or more with a multi-year commitment.

The table below puts the six side by side. Click a column header to sort.

Axis 2: pricing models

Pricing decides who carries cost risk. The rule that prevents most disputes: whoever controls the scope should carry the risk of it changing. More detail, with contract examples, in staff augmentation pricing models.

Two hybrids show up often and work well. A fixed-price discovery phase followed by a monthly team fee lets you buy certainty where the scope is clear and flexibility where it isn't. A monthly fee with a small outcome component (for example, a bonus or penalty tied to release frequency or defect rates) aligns incentives without pretending a team can promise a fixed scope.

Axis 3: location

For a US company, location is mostly about shared working hours, and only second about rates. The labels are often misused, so here's what they mean from a US point of view. The full comparison is in onshore vs nearshore vs offshore software development.

Rates between Latin America and Central Europe are now close, so the choice there turns on overlap, domain experience and the specific vendor. Asia remains the cheapest per hour, but the near-zero overlap pushes teams toward written, asynchronous work and makes fast iteration harder. See nearshore software development rates for the country-by-country numbers.

The hidden variable: your own management time

Proposals compare rates. They rarely mention how much of your own people's time each model consumes, and that's often the bigger cost. These are the ranges we see for a team of about five engineers, measured as hours per week from someone senior on your side.

This is why a cheaper rate in staff augmentation can lose to a higher monthly fee for a dedicated team: if your only senior engineer spends half the week managing augmented developers, you've bought capacity and spent leadership. It's also why project-based work feels cheap during the build and expensive at acceptance, when someone on your side has to verify everything at once.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Real estateModernizing a Multi-Service Real Estate Marketplace→FinTechAndroid application for FinTech industry→Pharmacy · DACHRedesigning and modernizing an Online Pharmacy mobile app→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Decide in this order

Most bad engagements we see in first calls were chosen in the wrong order: someone picked a country because of rates, then a vendor, then accepted whatever model the vendor sold. Reverse it.

1. Relationship first: who will manage the work?Be honest about how much senior time you have, using the table above. That narrows six models to two or three.
2. Pricing second: who controls the scope?If the scope is written and stable, fixed price. If you'll steer it, pay for time or a team. The pricing should follow the relationship, not the other way round.
3. Location third: how much overlap do you need?Daily pairing and live product discussions need 4+ shared hours. Well-written tickets and async reviews work with 2–3. Then compare rates within the regions that pass.
4. Vendor lastShortlist vendors that actually run the model you chose at the size you need. A vendor that mostly does fixed-price projects will run a dedicated team like a project, and vice versa.

Which model fits your situation?

Six questions about control, scope and scale. The quiz picks a relationship model; the result also suggests the pricing that fits it.

Combinations that work

A model is one choice on each axis. These are the combinations we see succeed most often for US companies, and the ones we'd steer away from.

Worked example: one company, three axes

A 60-person healthcare scheduling company in Chicago has a live web product, two in-house engineers and a VP of Product. It wants a patient-facing mobile app within nine months and then ongoing development of both products.

• Relationship: the two in-house engineers are fully loaded and nobody can manage five more people. That rules out staff augmentation. The app will change after the first patients use it, which rules out a pure fixed-price project. The answer is a dedicated team with its own lead, reporting to the VP of Product, after a short discovery.
• Pricing: a fixed price for four weeks of discovery (user flows, backlog, architecture, an estimate range), then a monthly fee for a team of a tech lead, three developers and a part-time QA engineer, with 30-day scale-down notice per person.
• Location: Chicago is one hour behind New York. A Central European team shifting its day to 10:00–18:30 local time shares about two and a half hours with a Chicago office that starts at 9:00 (9:00–11:30 Central). That's enough for a daily standup and decision calls if the team writes good handoffs; a Latin American team would give five or more hours at similar rates. The company weighs overlap against domain experience in HIPAA-regulated products and the vendor's references, and picks on those.

Notice what decided each axis: management capacity, scope stability and overlap needs. Rates only entered at the end, as a tiebreaker between regions that passed the overlap test.

How the right model changes as you grow

Models aren't permanent. In our experience companies move along a fairly predictable path, and planning for the next step avoids a painful switch later.

1. Idea to MVPFixed-price discovery, then a small dedicated team or a fixed-price MVP if the scope is truly narrow. Budget for the discovery even when money is tight: it is the cheapest place to find out the scope is wrong.
2. Product-market fitA dedicated team that grows with the roadmap; first in-house hires take over product and architecture roles.
3. ScalingIn-house engineering leadership with staff augmentation for capacity peaks and specialized skills.
4. MaturityManaged services for stable parts of the platform, dedicated teams for new product lines, and an ODC or BOT if offshore headcount passes a few dozen.

FAQ

Where Gilzor fits

We work in staff augmentation, dedicated teams, ongoing development support and fixed-price projects (including discovery phases and our fixed-price mobile app audit). If your quiz result points to an ODC or BOT program, compare vendors that specialize in building and transferring offshore centers.

Our engineers work from Poland and Cyprus, which for US companies is offshore with a partial overlap. We agree a fixed daily window, usually the East Coast morning, in the proposal. Over 7+ years and 70+ launched projects, the model we recommend most often for startups and SMBs is the fixed discovery followed by a dedicated team.