Offshore delivery partners, answered in full.

Use one where the work can be specified: engineering volume against a written requirement, an overnight or weekend rota, or a bench you need to scale to twenty people and then hold. The cost advantage is real and large, with TCS listing offshore rates between roughly a quarter and just over half of its own onshore rates for the same SFIA level on the G-Cloud 14 framework. Use a small onshore firm like Tenhaw for the part that cannot be specified yet, which in agentic work is usually the first few months: which exceptions matter, what the data actually contains, where a human stays in the loop, and how roles and decision rights change once an agent takes a decision. Plenty of programmes should buy both, with the boundary written down.

Per head, yes, and by more than most buyers assume. On its own G-Cloud 14 rate card TCS publishes an offshore Level 5 (Ensure, advise) rate in strategy and architecture of £445 a day against £1,330 onshore, and an offshore Level 3 (Apply) rate in development and implementation of £270 against £960. Across that card the offshore price sits between roughly a quarter and just over half of the onshore one for the same level, depending on grade and category. Three caveats travel with those figures. They are competitively tendered public-sector framework rates rather than private commercial ones. They are one supplier's card, not the market. And the document carries no publication date; it was uploaded to the framework in March 2025. The larger caveat is that cost per head is not cost per outcome, and the comparable number is team size times duration.

Nearshore trades part of the cost advantage for overlapping working hours, and on agentic work the overlap is usually worth more than the saving, because the expensive thing is not the engineering hour, it is the day lost waiting for an answer about your own data. Past that the two behave the same way. Both are strongest where the requirement can be written down and weakest where it is still being discovered, and neither is normally contracted to change roles or decision rights inside your organisation.

Three things, and none of them is engineering skill. Start with discovery, since agentic workflows are defined by their exception cases, and those live in the heads of people in your building who can give you twenty minutes at a time. Then there is decision latency. A question that takes ten minutes in the room takes a day when it has to be written down, answered overnight and clarified the day after, and this kind of work generates a great many questions. Last is the organisation itself. The software can be built anywhere, but changing whose job it is to approve something has to happen where the job is.

Yes, and it is a sensible shape. A common split is that discovery, the operating model, the evaluation criteria and the governance happen onshore and in the room, and the engineering volume that follows a settled specification goes offshore. Tenhaw also sells Programme and Delivery Management on its own at £18,000 to £35,000 a month, with no requirement that we build anything, so we will govern a programme another supplier is delivering. We would write the boundary down, including which side of it we are the wrong choice for.

That is a question for your own data protection officer, and worth asking before the price conversation. An offshore model normally means access from outside the UK, which makes it an international transfer with the paperwork that follows: an IDTA or standard contractual clauses, a transfer risk assessment, and sub-processor notification. Tenhaw's own default is to work inside your estate under your controls rather than copying data to ours, and our Data Processing Agreement covers the same ground, including the sub-processor annex and published insurance cover levels. Neither position is automatically right. A transfer assessment discovered at contract stage is simply the expensive place to find it.

Often yes, and for a structural reason. The offshore model depends on written specifications, documented handovers and test automation, so the delivery process is built to produce all three. That is a real advantage once the requirement is settled. The catch is the phase before that, where the design changes weekly while you find out which exceptions matter and what your data actually contains, so a specification written in week one documents a guess. Tenhaw writes things down as decisions settle, and the code, documents and work product are all yours, with an exit date agreed at kickoff. Ask any supplier what they leave behind, and when.

If the volume is real and lasting, yes. A deep bench is what the offshore model exists for, and it means ten engineers next month, twenty the month after, held for years, at rates that sit between roughly a quarter and just over half the same firm's onshore rates on TCS's published G-Cloud 14 card. Tenhaw works as two or three senior people and does not scale that way. The argument is sequence rather than exclusivity. Months where nobody can write the specification yet suit a small team in the room, and the volume that follows a settled specification suits the bench. If the capacity gap is permanent, recruiting your own team is a stated deliverable of ours.

Only for the parts that genuinely run overnight: batch jobs, a weekend rota, a support desk handing over round the clock. That is real coverage, and a UK firm in one time zone cannot provide it, so Tenhaw has no overnight or weekend cover. The trap is buying it for build work that does not need it, because while a workflow is still being worked out a time-zone gap turns every unanswered question into a day of waiting. A sensible shape is one time zone through discovery and build, then a follow-the-sun partner for run and support once the system is stable and specified.

Usually nobody, so plan for it deliberately. Very few offshore engagements are contracted to change roles, incentives or governance inside the client's organisation, and it is hard to do from another country in any case. Agentic systems move decision rights, and nobody adopts a system that makes their own role incoherent, so software landing into an unchanged organisation tends to sit unused whatever it cost to build. Either your own leadership owns that work with time in the diary for it, or you contract it onshore alongside the build. Tenhaw puts adoption and operating-model change in scope, in your building and with your managers, because it is usually what decides whether the software gets used.

Against a settled specification, often yes, and it is a fair thing to ask for. Most offshore engagements are rate-based rather than fixed, because a fixed price needs a scope that will hold, and the early months of agentic work are spent finding out what the scope is: which exception cases matter, what your data actually contains, where a human stays in the loop. Fixing a price on that means somebody is pricing a guess. Our own ways in are fixed on purpose, with a proof of concept at £20,000 to £55,000 over two to four weeks. Once the design has settled, a fixed offshore price for the build is very buyable.

Convert the rate into people before you compare anything. TCS's published G-Cloud 14 card puts its offshore price between roughly a quarter and just over half its own onshore price at the same SFIA level, so at the wide end, £445 a day against £1,330, three offshore people cost about what one onshore person costs, and at the narrow end it is closer to two. Then multiply by months, because the comparable unit is team size times duration. A larger team running longer at a lower rate can land anywhere at all against a smaller one, and the weeks spent waiting for answers about your own data land in the duration rather than in the rate.

That stays with you unless you contract somebody for it. An offshore engagement is normally written against a specification, so the supplier is accountable for building what the document says and closing the tickets, which is the right deal once the document is right. Whether the workflow actually works, whether the exception cases in it were the real ones, and whether anyone uses the result, sits on your side of the line by default. Tenhaw takes that end instead: one UK partner accountable for the outcome, measurable value delivered every month and reported against, and a month that delivers none written up as a failed month.

The practical test is whether the design has stopped changing. Ask three things: do we know which exception cases matter and how each one is handled, do we know where a human stays in the loop and who that human is, and does the risk function already know what evidence it will be shown. If all three hold and the last month of building produced no material change to the answers, the requirement will hold long enough to hand over, and engineering volume against it is where the offshore rate advantage is close to pure gain. If any of them is still moving, a specification written now documents a guess and somebody will pay to rewrite it.

Sometimes, and it is one of the honest reasons to use them when cost per head is the binding constraint and somebody onshore is already directing the work. The question is what that person is there to do. Relaying questions to another time zone is a different job from owning a design that changes weekly, sitting with the people who know how the exceptions are really handled, and moving decision rights inside your organisation. If the onshore lead has authority and diary time with your subject-matter experts, the model holds up well. If they are a conduit, every question still costs a day and you have paid a premium for the relay.

It depends what is making it late. If the team is waiting on answers about exception cases, data or who signs off what, the delay is decision latency rather than engineering speed, and moving the code onshore without moving the decisions changes nothing. Settle the design with the people who own the rules, then hand the specified work back. If the requirement is settled and the build is simply slow, re-shoring it buys a higher rate for the same problem, and the fix sits inside the delivery process rather than in the geography. Work out which of the two you have before anyone reopens a contract.

More of your own people than the build plan usually assumes, and mostly not engineers. Month one goes on finding out which exception cases matter, what your data actually contains and what your risk function will need to see, so it needs the subject-matter experts who know why a field is blank in a small share of records, the manager who owns the rule when it turns out to be ambiguous, and someone from risk early rather than at the end. Those people give you twenty minutes at a time, which works in the room and badly across a time zone. Agree their diary time before the contract, not after.

They can do the engineering, and at a scale a small team cannot, because the offshore model is built on written specifications, documented handovers and test automation. What is hard to do from another country is decide what the data should have meant. An agentic build surfaces the field that is blank in a small share of records, the code two teams have been using differently and the exception everybody handles by memory, and resolving those is a conversation with the people who entered the records and the manager who owns the rule. Settle the meaning onshore, write it down, and the cleanup that follows is exactly the specified, high-volume work an offshore partner is good at.