Engineering · 7 min read
Fixed price, dedicated team or ODC: how to choose
The way you pay for software shapes what you get. A practical guide to fixed price, dedicated teams and offshore development centres, and the safeguards each one needs.
Two projects with the same budget and the same agency can end very differently because of one early decision: how the work is bought. The engagement model decides who carries the risk when plans change, how quickly you can react to what users tell you, and how much of your own time the project will take.
We offer three models. None is better in general. Each fits a particular kind of project.
Fixed price
You agree a defined scope, a price and a delivery date before development starts.
When it fits
- The requirements can be written down clearly and are unlikely to move: a company website, a booking system with known rules, a rebuild of something that already exists.
- You have a fixed budget approved in advance, perhaps from a grant, a board or a single client contract.
- You want to know the total cost before committing.
What to watch
Fixed price only works if the scope is genuinely fixed. Because the supplier carries the risk of overruns, the price includes a margin for uncertainty, and any change after sign-off goes through a change request with its own cost and timeline. That is fair, but it can feel slow if you are still discovering what you need.
The protection here is a good discovery phase. We do not quote a fixed price from a two-line brief. We run research and discovery first, produce wireframes and a written specification, and price against that. The specification then becomes the shared reference when anyone asks "was that in scope?"
Dedicated team
You get a team (for example a product designer, two developers and a part-time QA engineer) who work only on your product, usually billed monthly. You set priorities; the team plans and delivers in short sprints.
When it fits
- You are building a product that will keep evolving: a SaaS platform, a marketplace, an internal system that grows with the business.
- You expect to learn from users and change direction as you go.
- You want speed to market without hiring a full in-house team yet.
What to watch
You pay for capacity, not a fixed outcome, so the cost depends on how well the backlog is managed. Someone on your side needs to be available to make product decisions, review work at the end of each sprint and keep the priorities honest. Without that, a dedicated team can stay busy without moving the business forward.
Scope changes are simple in this model: a new idea goes into the backlog and is prioritised against everything else. Nothing needs to be renegotiated, but every addition pushes something else back.
Offshore development centre
An offshore development centre (ODC) is a longer-term arrangement where we set up and run a team that works as an extension of your in-house technology department. Your engineering leads direct the work; we handle recruitment, line management, equipment, workspace, payroll and retention.
When it fits
- You already have an internal technical team and a roadmap that needs more people for a year or more.
- Hiring locally is slow or expensive, and you want stable, long-term capacity rather than project work.
- You want the team to use your tools, your code review process and your engineering standards.
What to watch
An ODC takes a few months to reach full speed while people learn your systems and culture. It needs investment from your side: onboarding, documentation, inclusion in planning and the same communication your in-house staff get. Treated as a remote branch of your own team, it works well. Treated as a ticket queue, it rarely does.
Side by side
| Fixed price | Dedicated team | Offshore development centre | |
|---|---|---|---|
| Best for | Clear, stable scope | Evolving products | Long-term extra capacity |
| You pay for | An agreed deliverable | Team time, monthly | A managed team, ongoing |
| Change handling | Change requests | Backlog reprioritisation | Your own process |
| Your time needed | Low to medium | Medium (product owner) | High (technical leadership) |
| Typical length | Weeks to a few months | Months | A year or more |
| Who carries delivery risk | Mostly the supplier | Shared | Mostly you |
Time zones: the hidden advantage
Nigeria runs on West Africa Time (WAT), one hour ahead of UTC with no daylight saving. For a team working Lagos or Abuja hours, that means:
- United Kingdom. In summer, when the UK is on British Summer Time, WAT is the same clock time as London. In winter, Lagos is one hour ahead. Either way the working days overlap almost completely.
- Western and central Europe. Berlin, Paris and Amsterdam are on the same time as Lagos in winter and one hour ahead in summer. Again, close to a full shared day.
- North America. A 9am start in New York is 3pm in Lagos in winter and 2pm in summer, so a standard working day gives two to three hours of overlap. That is enough for a daily stand-up and a review, with the build happening while you sleep.
For dedicated teams and ODCs, overlap matters more than people expect. Questions get answered the same day, and sprint ceremonies happen at sensible hours for everyone.
Safeguards that apply whichever model you choose
The model changes how you pay. It should not change how your business is protected. Before you sign with any supplier, check for these:
- An NDA before discovery. You should be able to explain your idea in detail without worrying where it goes. We sign one before the first proper workshop.
- Written ownership of everything produced. Paying for work does not automatically mean you own it. The contract should state that designs, source code, documentation and data belong to you, and should include a written assignment of intellectual property.
- Accounts in your name. Domains, hosting, cloud accounts, app store accounts, analytics and code repositories should be registered to your organisation, with the supplier added as a user. This makes changing suppliers possible without a hostage negotiation.
- Plain contracts. Payment milestones, change handling, warranty periods and notice terms written so a non-lawyer can follow them. If a clause needs a long explanation, ask for it to be rewritten.
- Access to work in progress. You should be able to see the code repository and a staging version of the product throughout, not only at the end.
- Data protection terms. If the supplier will handle personal data, the contract needs processing terms that meet the law where your users live, such as Nigeria's Data Protection Act, UK GDPR or EU GDPR.
A simple way to decide
- If you can describe the finished product in detail today and the budget is fixed, choose fixed price.
- If the product will change as you learn and you can give it a decision-maker, choose a dedicated team.
- If you have engineering leadership and need long-term capacity, choose an offshore development centre.
Many clients move between them. A common path is a fixed-price discovery and MVP, then a dedicated team once the product has users. If you are unsure which suits your project, tell us about it and we will recommend one, with the reasoning.