Nearshore only works if the contract, the data and the calendar all line up

What nearshore means in practice, not in a brochure

Nearshore is usually sold as a cost argument. That is the least interesting part of it, and it is the part that goes wrong most often, because a cheap hourly rate applied to an unclear scope produces an expensive project. The parts that actually decide whether the arrangement works are dull: how the scope is written, what a stage delivers, who owns the output, where the data sits, and what happens when something is late.

The genuine advantage of a near time zone is not that meetings are convenient. It is that a question asked at 09:00 in Munich is answered the same morning rather than the next one, which means a blocked decision costs hours instead of days. Over a three-month build that difference compounds into weeks, and it is the only geographical advantage worth paying for.

We have been building operational software since 2019, and the working language with clients outside Türkiye is English throughout: specifications, demos, code comments where they matter, and the handover documentation.

The calendar, stated precisely

Türkiye is on UTC+3 year-round and does not change clocks. The consequences are easy to compute and worth computing before anyone promises a rhythm.

• Central Europe. One hour behind us in summer, two in winter. A 09:00 start in Istanbul is 07:00 or 08:00 in Berlin, Paris, Amsterdam and Milan; the overlap covers the whole European morning and most of the afternoon.
• The UK. Two hours behind in summer, three in winter. The overlap still covers the UK morning comfortably, and it is the case where an afternoon call has to be scheduled rather than assumed.
• The Gulf. One hour ahead of us. The day is effectively shared, and the practical difference is the working week rather than the clock.

Two calendar details matter more than people expect. The two religious holidays move each year against the Gregorian calendar, so they are agreed into the plan at the start rather than discovered. And the Turkish working week is Monday to Friday, which is worth stating when the client is in a Gulf market where it is not.

Engagement models compared

Most of the risk in a nearshore engagement is decided by the model, before any code is written. These are the three that are actually used, and what each one is good and bad at.

We default to the staged programme because it makes the risk visible early and cheaply: the first module is small, it is in production, and it is a real test of whether the working relationship functions. If it does not, you have spent one module rather than one budget.

Contracting, ownership and the exit

The clause worth reading before any other is the one about ownership. Source code, database schema and intellectual property transfer to the client on delivery. There are no per-user licences, no runtime keys and no component that stops working if the relationship ends. The repository, the deployment configuration and the documentation are handed over as part of delivery rather than on request.

That is a commercial position as much as a technical one. A supplier who holds the code has an incentive to make leaving expensive, and every subsequent negotiation happens in that shadow. We would rather be kept because the work is good. Our reasoning on this is set out at more length on the source code ownership guide.

Payment follows stages rather than hours: a stage is defined, delivered, demonstrated running and then invoiced. Contracts are in English, and prices are quoted in USD or EUR against the published bands on pricing.

IR35: what a UK buyer is actually assessing

This is not tax advice and it is not a status determination. KodDelta is a software studio, not a tax adviser or a law firm. Nothing in this section tells you what your position is. It describes how we are structured to work, in enough detail that your own tax adviser or employment lawyer has something concrete to assess. The conclusion is theirs and yours, never ours.

UK clients raise this before the technical questions, and reasonably so. HMRC guidance for clients states that an organisation receiving contracted out services from a third party, such as an outsourcing company, will not have to apply the off-payroll working rules, and that this will be the responsibility of the organisation supplying a worker's services (GOV.UK, Off-payroll working for clients).

The same page closes the obvious loophole in the next breath: you should take care to make sure that a contract has not been relabelled to avoid the off-payroll working rules. UK tax practices put it more bluntly. Forvis Mazars writes that labelling a contract as a contracted-out service or a statement of work, when in reality the contract contains a provision for labour, will not prevent the IR35 off-payroll working rules from applying (Forvis Mazars). Bauer and Cottrell describe it as a question of fact, based upon the commercial reality of the arrangements (Bauer and Cottrell).

So the drafting is not the test. What happens week by week is the test. That is precisely why this belongs on an engineering page rather than in a legal appendix: the answer is decided by the delivery model, and the delivery model is chosen long before anyone opens a contract template.

Where the two arrangements differ in practice

The factors below are the ones UK guidance and practitioner commentary keep returning to. The middle column describes a time-based developer supply arrangement generically; the right column describes how we deliver. We are not telling you which side any particular engagement falls on, because that is a question of fact and your adviser is the one who answers it.

What the contract should say

If your adviser wants the arrangement documented rather than assumed, these are the clauses that describe how we already work, and we will sign them. The list is short and literal on purpose: a clause we could not honour in practice would be worse than no clause at all, because it is exactly the mismatch between paper and practice that the guidance warns about.

• A deliverable, not a resource. The subject of the contract is a named module and what it must do, not a quantity of engineer time.
• Acceptance criteria and a date. Written per stage, so that "delivered" is testable rather than negotiable.
• Payment against accepted stages. No timesheets, no hourly reconciliation, and no entry into your time recording system. The stage prices come from the bands on pricing rather than from a rate card.
• Our right to assign and substitute. We decide who does the work and may replace people without your approval. No individual is named in the contract beyond a single delivery contact.
• Direction and control stay with us. You specify what the module must do; we decide how it is built and who builds it.
• Our own equipment and premises. We do not need client hardware, client desks or client employment infrastructure in order to perform.
• Defect remedy at our cost. A stated warranty period during which we fix what we delivered, on our own account.
• Source code and IP assignment on delivery. The same clause described in the ownership section above and in the source code ownership guide, which also evidences that you bought an output rather than an input.
• No employment relationship. An express statement that nothing in the agreement creates one between your organisation and our personnel.

What we do not do

• We do not place developers inside your team. Nobody on our side takes daily direction from your managers or joins your stand-ups as a resource.
• We do not bill by the hour. There is no day rate, no timesheet and no monthly capacity invoice.
• We do not run candidate interviews for a seat. You are not selecting an individual; you are buying a delivered module.
• We do not backfill vacancies or lease personnel. Staff supply is not a service we offer, in any market.
• We do not take instructions on how the work is done. Only on what the module must do, and that is written down.

Read that as a limitation as much as a position. If what you actually need is two engineers embedded in your own squad, taking direction from your own tech lead, we are the wrong supplier and UK staffing firms exist for exactly that requirement. Our model sits at the fixed-scope end of the market rather than the dedicated-team end, which is the same distinction drawn in the nearshore cost comparison.

One thing to check before any of this matters

GOV.UK states that the off-payroll working rules apply to all public sector clients and to medium and large private and voluntary sector clients, and that small private-sector clients are outside them, with responsibility remaining with the worker's own intermediary. Where the rules do apply, issuing the status determination statement is the client's obligation rather than the supplier's. The company size thresholds that decide what counts as small have been revised and the change phases in across the coming tax years, so read the current version of the guidance rather than any summary of it, this one included, and put the question to your own adviser before it becomes a commercial term. If it helps to have our side of it in writing first, ask for it with the written scope and your adviser can read both together.

Sources: GOV.UK, Off-payroll working for clients; Forvis Mazars, Be wary of the contracted out services get-out; Bauer and Cottrell, A guide to contracted out services; BDO, Off-payroll rules: how IR35 works for businesses using contractors. Checked August 2026. KodDelta is an independent software supplier and is not a tax adviser or a law firm. The off-payroll position of any engagement is a matter for your own professional adviser, and HMRC assesses the reality of the working arrangement rather than the label on the contract.

Data protection and where the system runs

For a European buyer this is usually the question that decides whether the engagement happens at all, so it is settled at the start.

• Deployment location is your choice. An EU region, the UK, Türkiye, or your own cloud account. For clients with a data protection officer, deploying into infrastructure the client already owns is usually the cleanest answer, because the data never leaves their control and the discussion becomes about access rather than about transfer.
• Development runs on anonymised or synthetic data. Production data is not copied into development environments as a matter of routine, because the safest processing arrangement is the one where the data was never there.
• Access is named and recorded. Who on the team can reach which environment is written down and revoked when it is no longer needed, which is what an auditor asks for and what most engagements cannot show.
• The paperwork exists before the work does. Processing agreement, defined scope of processing, and the retention and deletion rules for anything we do hold.

The wider question of where corporate data lives and who controls it is covered in the data location guide.

How the work actually runs

The rhythm is deliberately unremarkable, because the failure mode of remote work is not distance, it is ambiguity.

1. Scope in writing, before estimates

   What the module does, what it does not do, which systems it touches and what "done" means for each screen. An estimate against an unwritten scope is a number with no meaning, and we would rather spend two days on the description than three weeks on the wrong build.

2. A clickable prototype in 2 weeks

   Screens and flows you can click through before production code is written. This is where misunderstandings surface cheaply, and it is the point at which most clients change something significant — which is exactly what it is for.

3. First module live in 2–4 weeks

   Real users, real data, in production, at $3,000–6,000. Not a pilot in a sandbox: the point is to learn whether the working relationship and the software both survive contact with the organisation.

4. Stage by stage, each one live

   Weekly call, written decisions, demo of running software at each stage boundary. A multi-department system reaches $8,000–15,000 over 4–8 weeks; an enterprise platform $20,000+ over 3–6 months. Nothing waits for a single launch date.

What we build, so you can judge the fit

The work is operational rather than consumer: systems that a company runs on. Custom ERP and operational platforms covering production, inventory, procurement and approvals, described on custom software. Process automation that removes repeating white-collar work, on business process automation. Integration bridges to accounting packages and marketplaces, on integrations. And retrieval-based AI assistants working on a company's own documents and data, on AI integration.

Systems already delivered and running are listed on cases, and the longer written argument for the model is in the nearshore guide.

When nearshore is the wrong answer

• The work needs someone in the room daily. Physical installation, hardware commissioning and shop-floor change management have an on-site component that no time zone fixes.
• The requirement cannot be written down yet. If the organisation is still arguing about what the process should be, the first job is that argument, not software.
• Governance forbids external access outright. Some regulated environments do, and the honest answer is an internal team.
• The job is a few days long. Coordination cost is roughly fixed regardless of size, so very small pieces of work are cheaper done internally.

Frequently Asked Questions