Onshore, nearshore, offshore: what the terms mean
The terms describe where the partner is located relative to you. Onshore means a partner in your own country. Nearshore means a partner in a nearby country, usually in the same or a neighbouring time zone. For a company in Germany, Austria, Italy or the UK, that typically means a partner elsewhere in Europe. Offshore means a distant country with a large time difference.
Location is only half of the decision. The other half is the engagement model, in other words who leads the work and who is responsible for the result:
| Model | Who leads the work | Who owns the result | Typical use |
|---|---|---|---|
| In-house team | You | You | Long-term core product |
| Dedicated development team | The partner's lead, with your product owner | Shared, as agreed in the contract | Longer projects that need a stable team that can grow |
| Staff augmentation | You | You | Filling skills gaps or adding capacity quickly |
| Project-based outsourcing | The partner | The partner, for the agreed scope | Well-specified, time-limited work |
Any engagement model can be onshore, nearshore or offshore. A nearshore dedicated team and an offshore staff augmentation contract are very different arrangements, even if both are labelled "outsourcing".
When each model works
- In-house works best when software is your core competitive advantage, the work is ongoing and it depends on deep domain knowledge. The price is slower hiring and less flexibility.
- A nearshore dedicated team fits longer projects that need regular, often daily collaboration and a team that can grow or shrink with the work. Overlapping working hours make joint planning, reviews and quick questions part of the normal day.
- Staff augmentation is the fastest way to add a specialist, for example a data engineer or a mobile developer, but only if you already have strong technical leadership. Without it, you are buying hours, not results.
- Project-based outsourcing is a good fit for an integration, a migration or a separate module with clear requirements. It struggles when requirements keep changing.
- Offshore can work for clearly specified, less domain-heavy work that does not need real-time collaboration.
In practice, combinations are common: product ownership and architecture in-house, a dedicated team for most of the development and an augmented specialist for a specific skill.
Judge partners on quality, not the hourly rate
The hourly rate is the easiest number to compare and the least useful one. What determines the outcome is whether the partner delivers working, maintainable software at a steady pace. When you compare offers, look at the total cost of ownership: onboarding time, the management effort on your side, rework, delays and the cost of changing partners later.
Focus your evaluation on evidence:
- references from comparable projects, with people you can call,
- the seniority and stability of the actual team, not the sales team,
- engineering practices: code review, automated testing, CI/CD and documentation,
- security practices and, where relevant, certifications such as ISO/IEC 27001,
- communication: a named contact, regular reporting and fluency in your working language.
Governance and communication
Most outsourcing problems are management problems. Agree from the start who decides on priorities (your product owner), who approves architecture, what "done" means and how progress is reported. Shared tools help: your repository, your issue tracker and your CI pipeline, so that work is visible and stays with you.
Time-zone overlap matters more than it seems. A team that shares most of your working day can join stand-ups, answer questions within minutes and pair with your developers. With a large time difference, every unclear requirement costs a day.
GDPR, NIS2 and sector rules
If the partner can access personal data, for example through test data, logs or production support, it acts as a processor and you need a data processing agreement under Article 28 GDPR. The GDPR's rules on transfers to third countries (Chapter V) apply when personal data leaves the EU/EEA. A partner established and processing data in the EU/EEA avoids that question, provided its subprocessors and tools are located there too, so ask for the list.
If your organisation falls under the NIS2 Directive (EU) 2022/2555 or its national transposition, supply chain security is one of the required risk-management measures. The directive expects you to take into account the vulnerabilities of your direct suppliers and the quality of their cybersecurity practices, including secure development procedures. A software partner is exactly such a supplier, so put security requirements, incident notification and audit rights into the contract.
In the financial sector, the DORA Regulation (EU) 2022/2554 adds specific requirements for ICT third-party service providers. Healthcare and the public sector have their own rules. Check them before you sign, not after.
Contracts, IP and exit
EU law gives an employer the economic rights in software created by employees in the course of their duties. For work done by an external company, do not rely on assumptions: the contract must clearly transfer, or grant you exclusive rights to, the source code, documentation and other deliverables. Practical safeguards:
- source code in your repository from day one, with your company as the owner of the accounts,
- a clear list of open-source components and their licences,
- confidentiality covering your data and business logic,
- notice periods and agreed lead times for scaling the team up or down,
- an exit plan: handover of code, documentation, credentials and knowledge, with the partner's obligation to support the transition.
Validate the partner with a 30-day pilot
A proposal shows how a partner sells. A pilot shows how it works. Give the shortlisted partner a small but real task, agree on success criteria in advance and run it in your environment: first onboarding and a simple task, then a delivery with code review and tests, then a task that touches your domain or an integration, and finally a retrospective with your developers. The tool above generates a pilot plan and a checklist weighted to your situation.
Watch for red flags: you cannot meet the people who will do the work, the partner wants to keep the code or the IP, references cannot be reached, a low price is promised before anyone understands your requirements, or answers about security and subcontractors stay vague.
If your project involves integrations, consider the ERP selection checklist as well. If you would like to discuss your software project and the delivery model that suits it, talk to us.
