Outsourcing, a dedicated team or a fixed-scope project? Eight criteria to decide

Software outsourcing: three terms, two separate questions

Software outsourcing means having software work done by someone outside your own staff; it is an umbrella term. Under the umbrella sit different arrangements, and most of the confusion comes from assuming they answer the same question. There are really two separate questions: what are you buying, capacity or an outcome? And who manages the work?

• Dedicated team: you buy time and capacity; you manage the team and set its priorities.
• Fixed-scope project: you buy an outcome with a written scope; delivery is run by the supplier.
• Freelancer: one person, often for a short, well-defined piece of work. Mentioned here for comparison.
• Building your own team: finding, hiring and managing developers is on you. Mentioned here for comparison.

A dedicated team and a fixed-scope software project are two different forms of outsourcing. One more point is often mixed up: the payment model (fixed price, time and materials, hybrid) is not the same thing as the working model. For the payment side, see the table in how to read a software proposal; this article compares the working and management model.

The question of whom to hire and under which model comes after "off-the-shelf or custom?"; for that one, see the off-the-shelf or custom software worksheet. If you are going to commission custom software, this article gives you eight criteria, a decision worksheet and twelve questions to put to a supplier. We describe how the work runs on our custom software development page.

An eight-criteria comparison table

The cells are qualitative and worded with "generally"; you cannot give figures without knowing all the terms of a product or supplier, and we do not give any. Copy the table and extend it with your own notes.

Two things to watch when reading the table. First, the rows are not independent: in a model where you do not manage the work (criterion 1) the supplier usually carries the outcome risk (criterion 2), but in return the scope has to be in writing (criterion 3). Second, no model wins every row: your own team keeps ownership and knowledge in-house but is slow to start; a dedicated team is flexible but the management is yours; a fixed-scope project lowers your management load but demands a clear scope.

The table is a starting point, not a verdict: test with the questions below whether "generally" holds in your case.

Criterion by criterion: what to look at and what to ask

1. Who manages, and who answers to whom?

Software work most often goes wrong in the distance between the person who describes the job and the person who does it. Each model places that distance differently: with your own team and a dedicated team the management is yours; in a fixed-scope project delivery is run by the supplier. A good answer: who runs the day-to-day work and who makes the decisions is clear by name. A warning answer: "the team manages itself" but nobody says who sets priorities, or there is a relaying layer between you and the person doing the work. The question to ask: who is the decision-maker on this work and can I talk to them directly?

2. Who carries scope, schedule and cost risk?

Some uncertainty remains in every job; the question is who carries it. A good answer: risk sharing is in writing, and it is clear who absorbs which delay. A warning answer: a risk nobody owns under the banner of "flexibility." If you use a dedicated team, the outcome risk is largely yours; in a fixed-scope job, risk comes back to you once work goes outside the scope. The question to ask: if the schedule or the cost plan is exceeded, what happens, and is that in writing?

3. What happens when scope changes?

Scope often changes in software work; the models differ only in how a change is handled. With a dedicated team, changing priorities is easy; in a written-scope engagement a change is a decision. The general good practice is this: scope is not changed without a written update. A good answer: the change request is in writing, its effect on work, schedule and cost is in writing, and nothing is applied until you approve. A warning answer: a verbal "we'll do that too." The question to ask: how do I submit a change, and when do I get its effect in writing?

4. Continuity of knowledge and dependence on individuals

The person who wrote a system knows it best; when that person leaves, the system is yours only as far as it has been written down. This criterion is most visible with a freelancer, but it exists in every model. A good answer: more than one person knows the system, and the reasons for decisions and the setup are documented. A warning answer: everything is in one person's head. The question to ask: if a key person leaves, what happens, who replaces them and how is knowledge handed over? What you would get if you changed suppliers is shown by the "what to ask the previous team for" section of our guide to taking over an unfinished software project.

5. Ownership of code, accounts and intellectual property

Having working software does not mean it is yours; code, accounts and rights are asked about separately. A good answer: the code repository, servers, domain and third-party accounts are in your name, and the transfer of rights is in writing with the rights listed one by one. Under Turkish law, for instance, the transfer of an author's economic rights has to be in writing (Law No. 5846, Article 52); other countries have their own rules. A warning answer: the single sentence "the source code is yours" and accounts opened in the supplier's name. The question to ask: to whom do the code and rights pass, when, and by which document? This item is general information, not legal advice.

6. Visibility of progress

The only way to see a delay early is to see the work. A "status report" is not the same thing as "working software." A good answer: a live panel, a shared code repository, or a working build at every interim delivery. A warning answer: only meetings and reports. The question to ask: how will I see progress, how often, and independently of the supplier?

7. Flexibility to start and stop

With an uncertain product idea, stopping matters as much as starting. A good answer: the start condition, the exit condition and what the work so far turns into if you stop midway are in writing. A warning answer: an exit condition that is never written, or a setup that makes leaving practically impossible. The question to ask: if I stop midway, will you hand over what has been done so far, and the code?

8. Skill and time needed on your side

Outsourcing does not remove the management load, it only moves it. A good answer: what the model expects of you is in writing in advance: who, how often, which decisions. A warning answer: technical management is expected of you but nobody says so, or the promise is "you won't have to do anything." The question to ask: in this model, who on my side needs to set aside how much time each week, and which decisions are mine?

Not all eight criteria weigh the same on every job. In an internal tool, visibility and flexibility may come first; for a product opened to customers, ownership and continuity weigh more. That is why the decision worksheet below starts by weighting the criteria.

Which model when? Fixed-scope projects, dedicated teams and the rest

(a) A product or system whose scope can be written and whose outcome is clear: a fixed-scope software project fits. If you can put what you want into a document and say what will count as "done," buying the outcome leaves the management load with the supplier.

(b) A product that is developed continuously, with priorities that change weekly, and you have product and technical management in-house: a dedicated team fits. You steer the capacity and change is easy; in return, management and outcome risk are yours.

(c) One person, a short, well-defined job: a freelancer is often enough. There is no need to drag out the search for a developer on a small job; still, settle criteria 4 and 5, dependence on one person and the transfer of rights, in writing.

(d) The core of your software product, for many years to come: building your own team makes sense. The rule from a 2001 post on Joel on Software is: "If it’s a core business function — do it yourself, no matter what."

(e) Hybrid: a fixed-scope first version first, capacity afterwards. The first version of the product ships with a written scope and is then continued by a team whose priorities you manage. For small and uncertain ideas, see our MVP development page on how we cut the scope of a first version.

The choice rarely comes down to a single criterion. First ask "how describable is my work?": if it is describable, a written scope is an advantage; if not, you may need a small first step to get it into writing. Then ask "who can do the managing?": if you do not have product and technical management, a dedicated team will load you down. Finally ask "how easy should leaving be?"; your answer sets the weight of criteria 5 and 7.

An honest note: if your only criterion is buying time and capacity, another model will serve you better. For a mobile-specific comparison of ready-made tools, freelancers and agencies, see our mobile app development page; for how they differ on cost, see mobile app development cost.

Employment and tax notes on a dedicated team (Turkey)

A dedicated-team arrangement can raise questions of employment law, invoicing and tax in some setups. For example, Article 2 of Turkey's Labor Law (No. 4857) defines the principal employer and subcontractor relationship and says the principal employer shares liability with the subcontractor toward the subcontractor's workers for obligations tied to that workplace; Article 7 provides that a temporary employment relationship may be set up through a private employment agency or within a holding company or group of companies (mevzuat.gov.tr, in Turkish).

Whether a dedicated-team arrangement falls under either of these provisions depends on how the work is described and how the contract is built; that is a legal question and this article does not answer it. Under which company name, and with which line items, an invoice is issued is also a question to settle with your accountant. If your dedicated team is based abroad or you work outside Turkey, the rules of the countries involved come into play separately. Talk to a lawyer and an accountant before you sign. A practical rule: have the contract state plainly whose employees the team members are, who manages the work and in whose name invoices are issued; those three answers show your lawyer and accountant under which heading the question should be assessed. This section is general information, not legal or financial advice.

Decision worksheet: weight and score

Copy the table. In the first column write how important each criterion is for you (low, medium, high), in the next four columns write "fits," "partly" or "does not fit" for each model, and note your reasoning in the last column.

We do not give a threshold or a total-score formula. The result is this: a model that has no "does not fit" on any criterion you rated "high" can be a candidate for you. If two models meet that condition, look for the difference in the "partly" cells and in your notes. A fictional example: if criterion 5 is "high" for you and a model is "does not fit" on it (say the accounts are opened in the supplier's name and the handover is not in writing), that model remains a candidate only if the gap is closed in writing. If criterion 7 is rated "low," the same model sitting at "partly" there does not change the decision. Fill it in on your own first, then update it with the suppliers' answers (the twelve questions next).

Twelve questions to ask software outsourcing companies

Whatever the model, ask these questions in writing and get the answers in writing.

1. Who will manage this work day to day, who decides, and will I be able to talk directly to the person writing the code?
2. Whose account is the code repository in, and can I get to it at any time?
3. How do I see progress: a panel, a shared repository, interim deliveries?
4. How is a scope change written, and when do I get its price and schedule impact in writing?
5. If I leave, what do I get, in what format and when (code, data, documents)?
6. If a key person leaves, what happens, who replaces them and how is knowledge handed over?
7. Under which company name is the contract made, and in whose name are invoices issued?
8. Is the transfer of rights in writing, are the rights listed one by one, and under what condition do they pass to me?
9. In whose name will the third-party accounts in use (hosting, domain, payment, maps, AI) be opened?
10. Who provides support after launch, with what scope and what pricing?
11. If a defect appears after launch, who is responsible?
12. How is knowledge handed over: documentation, records of technical decisions, training?

If the answers are missing, evasive or only verbal, that is information too. A good supplier explains plainly how each question is answered in its own model; where the answer is "it depends," ask what it depends on and what that looks like in writing. Ask the list again after you receive the written proposal, not only in the first conversation: see how many of these questions the written proposal answers.

How we do it

Here we only repeat what we say on our site. We work project by project: every engagement is a paid project that starts with a written quote you approve. Scope, timeline and cost are in your hands in writing before anything is billed. You talk directly with the engineer writing your code, and once development starts a live project panel shows status, quotes and payments.

Ownership of the delivered work passes to you when the project is paid in full, and nothing we run for you is a reason you cannot leave. After launch we give direct support; anything beyond that is sized to the project. As we say on our home page, if you need a template site, only the lowest price or only a visual design, another route will serve you better. We describe how we work on our custom software development page; details are on our Process and Terms pages. If you have a job whose scope can be written, tell us about your project.

Frequently asked questions

Is outsourcing the same as a dedicated team?

No. Outsourcing is the general name for having work done outside your own staff. A dedicated team is one form of it: you buy time and capacity and you manage the work. In a fixed-scope project you buy an outcome with a written scope and delivery is run by the supplier. The two are not mutually exclusive; the first version of a product can be a fixed-scope project and its later development can run with a dedicated team.

What happens if the scope changes in a fixed-scope project?

The general good practice is that a scope change is not made without a written update: the effect of the change on work, schedule and cost is notified in writing and nothing is applied until you approve. Ask the supplier whether this method is written into the proposal. For what to look for in a proposal, see the change management line in how to read a software proposal.

Who owns the code when you use a dedicated team?

It depends on the contract. Under Turkish law, Article 52 of Law No. 5846 requires contracts on economic rights to be in writing, with the rights concerned listed separately (mevzuat.gov.tr, in Turkish); other countries have their own rules. Even if you are only buying capacity, settle in writing how the code and rights pass to you. This answer is general information, not legal advice.

Which model is cheaper?

What you pay for differs: capacity in a dedicated team, an outcome in a fixed-scope project. Which is cheaper depends on how continuous the work is, how clearly the scope can be set and how much management time you have. We do not give figures here; ask for each model's quote in writing and with the same line items, and count your own management time too.

Which model fits a small, uncertain product idea?

Often the first step is to cut the scope: a first version with one main flow and a written scope. When uncertainty is high, learning with a small first version makes more sense than starting a large scope. We describe the method on our MVP development page.

Sources

The pages below were opened and read on November 2, 2026.

• In Defense of Not-Invented-Here Syndrome, Joel on Software, October 14, 2001
• Law No. 5846 on Intellectual and Artistic Works, Article 52, mevzuat.gov.tr, in Turkish · Labor Law No. 4857, Articles 2 and 7, mevzuat.gov.tr, in Turkish

This article is general information; it is not legal or financial advice.