What does offshore software development mean for a German company?
Offshore software development means a German company has software designed, written and tested by people in a country outside Europe, most often India, while the German side keeps the product decisions, the data and the ownership. The code arrives in your repository; the servers run in your cloud account; the people writing it simply sit several time zones east.
It is different from nearshoring, where the partner sits in Poland, Romania or another EU country, and from hiring freelancers in Germany. The legal consequences differ too. A partner inside the EU is not a third-country recipient under the GDPR; a partner in India is. A German employee's code belongs economically to the employer by law; an external developer's code does not, unless the contract says so. Those two points shape most of this page.
The model suits work that can be described in writing and checked on a test system: internal tools, portals, integrations, automation and self-contained product modules. It suits less well work that depends on walking the shop floor, sitting in a workshop room with twelve stakeholders, or maintaining hardware.
Offshore
The team works from a country outside the EU, such as India. Largest time-zone gap, lowest overhead, third-country transfer rules apply.
Nearshore
The team works from a nearby EU or European country. Smaller time gap, EU data protection by default, higher day rates.
Onshore
German freelancers, agencies or employees. Same language and hours, highest cost, and a shortage of developers to hire.
Does offshore software development work for the Mittelstand?
It works when a Mittelstand firm has one person who owns the software internally and can decide quickly. It struggles when nobody has time to answer questions, because an offshore team cannot walk down the corridor to ask.
Family-owned manufacturers, wholesalers and service firms often run on a mix of an ERP, spreadsheets and one ageing custom program written years ago by someone who has left. That is fertile ground for offshore software development: the processes are known, the pain is concrete, and the result can be tested by the people who use it daily. What they usually lack is spare developer capacity, which is exactly what a remote team adds.
Scale-ups are a different case. They normally have an engineering team and a backlog that is too long. For them offshore work fits best as a clearly bounded module with its own API, reviewed through pull requests by an in-house engineer, rather than as a second team editing the same core code in parallel.
- Good fit: a named product owner, written processes, staging systems, English on the German side
- Workable with effort: no documentation yet, but willingness to write it during a pilot
- Poor fit: decisions by committee, no internal owner, or work that requires physical presence
Is offshore software development in India GDPR-compliant?
It can be, but it needs a transfer tool, because India is not on the list of countries with an EU adequacy decision. The European Commission's adequacy page names countries such as Japan, the UK, Switzerland and South Korea; India is not among them. Any access to personal data from India is therefore a third-country transfer.
The usual transfer tool is the set of standard contractual clauses the Commission adopted on 4 June 2021 in Decision (EU) 2021/914. Your company, as the data exporter, picks the right module (normally controller to processor), and the clauses are signed alongside the processor contract. On top of that, the European Data Protection Board's Recommendations 01/2020, finalised on 18 June 2021, expect the exporter to assess whether the destination country's law and practice undermine the clauses, and to add supplementary measures where they do. That assessment is what German DPOs call the transfer impact assessment, or TIA.
Whether your transfer is lawful is a decision for your data protection officer or lawyer, not for us. What we can do is make the assessment easier by keeping the amount of personal data that ever reaches India as small as possible, and by answering your questionnaire precisely: which people access which systems, from which devices, through which tools, and for how long.
The AVV under Art. 28 GDPR when your processor sits in India
If our work touches personal data your company controls, we act as a processor, and Art. 28 GDPR requires a written processor contract, the Auftragsverarbeitungsvertrag (AVV) or DPA. Most German firms have their own template, and we work with the one your DPO prefers; the specific terms are agreed with your written quote.
Art. 28(3) lists what that contract must cover. Knowing the list helps you check any offshore software development proposal in a few minutes:
- Processing only on your documented instructions, including instructions about transfers
- Confidentiality obligations for every person with access
- Security measures under Art. 32 (encryption, access control, logging)
- Rules for sub-processors, with your prior written authorisation
- Help with data subject requests such as access or erasure
- Help with security, breach notification and impact assessments (Art. 32–36)
- Deletion or return of personal data when the work ends
- Information and audit rights so you can verify all of the above
Sub-processors deserve a line of their own. Every SaaS tool the team uses to handle your data, from the ticket system to a logging service, may count. We keep that list short and put it in writing before the pilot starts, so your DPO can approve it once instead of chasing it later.
Designing the project so less personal data leaves the EU
The simplest supplementary measure is structural: build and test offshore software against data that is not personal at all. Much of our work needs realistic records, not real people.
In practice that means a staging system filled with generated or pseudonymised test data, production databases that stay in your AWS Frankfurt or other EU account, and production access for the team only when a specific task needs it, logged and time-limited. Code moves through your Git repository and your deployment pipeline, so nobody has to copy a customer table to a laptop to do their job.
This approach costs a little more setup time in week one, mostly for a seed-data script and a separate staging environment. It pays back quickly: your TIA becomes shorter, your works council has fewer questions about employee data, and a lost password on our side exposes a test system rather than your customer base.
- Staging with generated data; production data stays in your EU account
- Personal accounts for each developer, protected by two-factor login
- Role-based access; admin rights granted per task and removed after
- Access and deployment logs you can export
- Secrets kept in a vault or cloud secret store, never in code
Who owns the code? Usage rights under German copyright law
Under German law you cannot buy the copyright itself; you receive usage rights. § 29 UrhG says copyright is not transferable (except by inheritance), and allows only the granting of Nutzungsrechte under § 31. So a contract that simply says the client "owns the code" is weaker than it looks.
Two further rules matter for offshore software development. § 31(5) UrhG says that where the types of use are not expressly listed, the scope of the rights follows the purpose of the contract, which leaves room for argument later. And § 69b UrhG gives the employer the economic rights in software written by its own employees, but that rule does not cover external developers. Code from a freelance team belongs to you only as far as the contract grants it.
That is why we recommend contract wording that grants your company exclusive, transferable usage rights, unlimited in time and place, for all known types of use, including editing, further development, sublicensing and use in other products. Your lawyer drafts or approves the exact clause; § 31 UrhG is the provision it builds on.
Source code handover
The repository lives in your GitHub, GitLab or Azure DevOps organisation from the first day, so handover is not an event at the end but a fact throughout.
Open-source components
Libraries stay under their own licences. We list them with their licence type so your legal team can check copyleft obligations.
Which contract type suits offshore software development under German law?
For a clearly defined deliverable, a Werkvertrag under § 631 BGB fits: the contractor owes a result, and payment follows formal acceptance. For ongoing capacity, where the team works through a backlog you prioritise, a Dienstvertrag fits better, because the team owes work, not a specific outcome.
Offshore projects often mix both. A pilot or first release is priced as a defined piece of work with acceptance criteria; later improvements run as monthly scope agreed in writing. Our step-by-step guide to outsourcing an app build goes deeper into acceptance (Abnahme) and specification documents, so here is only the short version of the clauses to look for.
- Exact deliverables, or the backlog process if the work is capacity-based
- Exclusive usage rights, repository ownership and documentation duties
- Acceptance procedure with test cases, if the contract is result-based
- AVV and SCCs as annexes when personal data is involved
- Governing law and venue, agreed with your lawyer
- Payment milestones and currency
Anything the quote does not settle falls back on our terms. We do not give legal advice, so the final wording should always pass your own counsel.
How are invoices from India handled? Reverse charge under § 13b UStG
Our invoices come from India, quoted and issued in USD, and are paid in USD or EUR by Wise or bank wire. Because the supplier is based abroad, German VAT is usually not charged on the invoice; instead the recipient business may have to account for it.
§ 13b UStG covers services supplied by an entrepreneur resident abroad, and § 13b(5) makes the recipient owe the tax where the recipient is an entrepreneur or a legal entity. For most German businesses that means the reverse-charge amount appears in their own VAT return and, if they are entitled to deduct input VAT, is deducted again in the same return.
How your company books our invoices, which account they land in and whether any exception applies is a question for your Steuerberater. We do not advise on German tax. What we provide is an invoice with the details your accountant asks for, a clear description of the service and the payment reference, and a milestone schedule so finance knows in advance what arrives when.
How much working overlap is there between India and Germany?
India Standard Time is UTC+5:30 all year and has no daylight saving. Germany runs on CET (UTC+1) in winter and CEST (UTC+2) in summer, so India is 4.5 hours ahead in winter and 3.5 hours ahead in summer.
In practice the German morning lines up with the Indian afternoon. A stand-up at 9:30 in Hanover is 14:00 in India in winter and 13:00 in summer. Calls fit comfortably between German breakfast time and mid-afternoon; after that the Indian evening begins. Written communication fills the rest: when your team finishes on Tuesday, a summary of what changed and what needs a decision is already waiting on Wednesday morning.
That rhythm has a quiet advantage for offshore software development. Questions you answer before lunch are worked on the same day, and fixes reported in the afternoon are often on the staging server before your next morning. The key is to batch decisions into the overlap window instead of expecting instant replies at 17:00.
Why start offshore software development with a pilot project?
Because a pilot tests everything a contract cannot: how questions are asked, how estimates hold, how code reads and how quickly problems surface. A pilot of four to six weeks with one visible deliverable tells you more than any reference call.
A good pilot is small but real. It runs on your infrastructure, passes through your DPO's paperwork, uses your repository and ends with something your staff actually use. Replacing one spreadsheet-driven process, building one integration, or adding one module to an existing portal are typical candidates. A proof of concept on dummy slides tests nothing.
Set exit criteria before you begin: was the estimate met, were questions clear and timely, would your in-house developer happily maintain this code, did the documentation let someone else deploy it? If the answers are yes, extend the scope. If not, you leave with working software, the source code and the documentation, and you have spent a pilot budget rather than a year.
- One process, one user group, one measurable outcome
- Real environments: your Git, your cloud account, your SSO where possible
- Weekly demo on staging, written notes after every call
- A short retrospective at the end with a go/no-go decision
What does offshore software development cost for a German firm?
With BtechWaleTech custom software starts at US$900 for 6–12 weeks of work, AI automation at US$600, and maintenance at US$120/mo after two free months. Offshore providers and German agencies quote very differently, and the difference mostly reflects overheads, team structure and risk margin rather than the quality of individual developers.
The things that really move a quote for offshore software development are the same everywhere, so understanding them lets you shrink the scope on purpose:
- Number of user roles, permissions and approval steps
- Interfaces to ERP, CRM, accounting or shop systems, and the quality of their documentation
- Data migration from old systems, especially cleaning duplicates
- Reporting and exports your controlling team needs
- Documentation depth for GDPR, IT security and internal audit
- Languages in the interface; German text supplied by you
- Test coverage and the number of environments
For a view of total cost of ownership over several years, including hosting and maintenance, the software development cost in Germany guide works through sample budgets.
How do you choose an offshore software development partner?
Ask for proof you can inspect, and ask questions a salesperson cannot answer. The people who will write your code should be on the first call, and their answers about data access and ownership should arrive in writing.
Send the same short brief to every candidate and compare the replies line by line. Pay attention to what they ask you: a partner who asks about your existing systems, test data and approval process has done this before.
- Who exactly works on our code, and can we speak to them before signing?
- Which personal data would you need, and how would you avoid needing it?
- Which SaaS tools would your team use with our data (sub-processors)?
- Will the contract grant exclusive usage rights for all known types of use?
- Will the repository sit in our own GitHub or GitLab account from day one?
- How do you estimate, and what happens when an estimate is wrong?
- What does a handover document contain?
- Who covers the work if one developer is ill?
A three-person team has an obvious answer to the last question: the other two have been reviewing every pull request. Ask any larger vendor how many people actually know your code.
Risks and red flags in offshore software development
Most offshore failures come from missing structure, not from distance. These warning signs show up early, usually in the proposal or the first two weeks:
- Code kept in the vendor's repository until the final payment
- A contract that talks about ownership but never names usage rights
- Requests for a full copy of production data “to test properly”
- No named people, only roles on a rate card
- Status reports without a staging link or demo
- Silence about sub-processors and security measures
- Promises that everything is included at a price that cannot be itemised
- Pressure to sign a long engagement before any pilot
There are also honest limits on our side worth stating. We do not visit sites, we do not supply hardware, we do not write German-language copy, and we cannot staff a large programme with a dozen parallel teams. If your project needs those things, choose a partner who can provide them.
Tech choices that keep offshore code maintainable in Germany
Pick a boring, widely known stack, because the real test of offshore software development is whether someone else can maintain the result. We default to TypeScript with Node.js and React for web applications, Python where data work or AI is involved, PostgreSQL for data, and Flutter or React Native for mobile.
Infrastructure lives in your cloud account, usually in an EU region such as AWS Frankfurt, described as code where the project justifies it. Deployments run through a pipeline in your repository, so any developer with access can reproduce them. Tests cover the business rules that would be expensive to break: price calculations, permissions, approval flows and data exports.
If the software has a public side, such as a customer portal login page, documentation or a product site, we also take care of the basics that search engines and AI answer tools read: fast pages, clean HTML, structured data, sensible titles and a sitemap. Nobody can guarantee rankings; clear, fast pages are simply the part we control. SEO support for a related website starts at US$150/mo.
Working with the team from Germany: calls, payments and the first two weeks
Everything runs remotely: video calls in English, WhatsApp for quick questions, and shared documents for decisions. There is no office in Germany and no site visits; contracts and invoices come from India.
Week one starts with a kick-off call to walk through the brief and your existing systems. You send the AVV template, the SCC module your DPO chose and any security questionnaire, and we answer every point in writing. Your IT team creates accounts for us in Git, the cloud console and the ticket tool, each with two-factor login. We write a short technical plan and a list of open questions.
Week two is about proving the plumbing: an empty application deployed to staging through the pipeline, test data loaded, the first real screen or endpoint working, and a weekly demo slot fixed in your calendar. Payments follow milestones set in the quote, in USD or EUR by Wise or wire, and nothing is billed before you approve the itemised estimate in writing.
Worked example: a wholesaler in Münster replaces an Access database
This is a hypothetical scenario to show how offshore software development could be set up; it is not a client project.
Say a family-owned wholesaler near Münster manages supplier complaints in an old Access database that only one employee understands. It wants a browser application with complaint records, photo uploads, supplier scoring and an export for its ERP. The data includes names and email addresses of supplier contacts, so the GDPR transfer rules apply.
We would propose a pilot covering complaint intake and the supplier list, built from generated test data, hosted in the wholesaler's own EU cloud account. Its DPO would add the SCCs and an AVV, and a short TIA noting that developers work on test data and access production only for deployments. The contract would grant exclusive usage rights; the repository would sit in the wholesaler's GitHub organisation.
The quote would start from the custom software line at US$900, with separate items for data migration from Access, the ERP export and German interface texts supplied by the client. After a successful pilot, scoring and reporting would follow as a second phase. The whole thing would likely take eight to ten weeks, depending on how quickly the old data can be cleaned.