Fixed price or dedicated team? Choosing the right contract for an offshore software project

Once you have chosen a development partner, the next decision shapes the whole project: how you buy the work. Get it wrong and you either pay for flexibility you never use, or fight about change requests for six months. Here is how the three common models really behave, from the perspective of a company buying software rather than selling it.

Fixed price

You agree a written scope, a timeline and a price before development starts.

Works well when the system is describable up front: a portal, a CRM, a marketplace, a replacement for something that already exists. You need budget certainty, or approval from someone who needs a number.

What it asks of you: real attention during discovery. A fixed price is only as good as the scope behind it, so the screens, roles and rules have to be agreed before the build.

Watch out for: quotes that are cheap because they exclude testing, data migration, deployment or documentation. Ask what is not included, in writing. Also agree how changes are handled: a sensible partner prices each change separately and tells you before starting.

Dedicated team

You pay monthly for named people who work only on your product.

Works well when the backlog will keep changing: a product finding its market, a platform with a long roadmap, or a business that wants an extension of its own team.

What it asks of you: someone on your side to prioritise every week. A dedicated team with no product owner drifts, and drift is expensive.

Watch out for: paying for capacity you cannot feed. If you cannot fill a developer's week with decisions and feedback, you are buying idle time.

Time and materials

You pay for hours actually worked, usually against an estimate with a cap.

Works well when the work is genuinely unpredictable: integrations with an undocumented system, research spikes, or maintenance where nobody can forecast next month's requests.

What it asks of you: tolerance for a variable invoice, and the discipline to review time reports.

Watch out for: open-ended arrangements with no cap and no reporting. Insist on weekly visibility of hours and what they bought.

A quick way to choose

• Can you describe the whole thing in screens and rules today? Fixed price.
• Will priorities change every few weeks, and can you steer weekly? Dedicated team.
• Is the work mostly unknown, or reactive support? Time and materials, with a cap.
• Not sure? Run a small paid discovery first, then fix the price of phase one. Discovery is cheap compared with building the wrong thing.

Mixing models

Most healthy long-term relationships end up mixed: a fixed price for the initial build, then a monthly support plan, then fixed prices again for each significant phase. That gives you certainty where the work is known, and flexibility where it is not. See support and AMC plans for how the ongoing part usually works.

Terms worth agreeing whichever model you pick

• Ownership: source code, designs, database and data belong to you once paid.
• Acceptance: what "done" means for each milestone, in writing.
• Data protection: a data processing agreement and the right transfer clauses if you are in the UK or the EU. See GDPR and offshore development.
• Exit: what happens to the code, the hosting accounts and the documentation if you leave.
• People: who actually works on it, and how changes to that are communicated.

How OASIS works

We quote most projects at a fixed price after a short discovery phase, and move clients onto a monthly support plan after launch. For products with a moving roadmap we work as a dedicated team instead. If you are weighing up an offshore partner more broadly, our guide for UK and EU businesses covers vetting and the common mistakes.

Tell us about your project and we will suggest the model that fits, even when it is not the biggest one.