Software Development in Germany: Hosting, GDPR and the Cost of Running It

Most software projects are evaluated on two numbers: the quote and the delivery date. Both are the least durable part of the decision. What determines whether a system is still an asset three years later is where it runs, how personal data is handled, and who is responsible when something breaks on a Tuesday morning.

Hosting location is an architecture decision, not a checkbox

For companies operating in Germany and the EU, hosting inside the EU is usually the default expectation — from customers, from works councils, and from procurement. But the location of the primary database is only half the story. Logs, backups, error tracking, email delivery, analytics, and AI inference all process data too, and they are frequently the components that quietly leave the region.

The practical requirement is a written data map: for every component, which provider, which region, which category of data, and which legal basis. If a partner cannot produce that list for their own default stack, it does not exist yet.

keep reading GDPR Compliant Software Development: The Custom Enterprise Guide

What GDPR actually asks of a custom build

• Data minimisation by design. Fields you do not need should not be collected — this is a schema decision made in week one, not a policy added later.
• Deletion and retention. Every entity needs an answer to "when does this go away, and what happens to the records that reference it".
• Access control that maps to roles. Row-level authorisation enforced server-side, not hidden UI elements.
• Processing records and DPAs. One agreement per processor, including the small tools — monitoring and transactional email are processors too.
• Auditability. Who accessed which record, and who exported what. Cheap to build up front, expensive to retrofit.
• Consent that reflects reality. Tracking and marketing scripts must actually stay off until consent exists.

Operations is where budgets are really decided

Development is a project; operations is a subscription. Before signing, get numbers for the boring parts: monitoring and alerting, patching and dependency updates, backup and restore testing, incident response times, and how new requirements are scheduled once the initial scope is delivered.

A useful test is to ask how a restore is verified. Teams that run real restore tests answer immediately. Teams that only configure backups start explaining.

Ownership: code, infrastructure and accounts

Ownership problems rarely appear during the build. They appear when you want to change partner. Three things should be yours from the first day: the repository, the cloud and hosting accounts, and the domains and DNS. A partner should work inside your accounts, or hand them over on request without renegotiation. Documentation of environments and deployment counts too — code you cannot deploy is not an asset.

keep reading How to Choose a Software Development Partner in 2026

Questions worth asking before you sign

Which regions do all components run in, including logs, backups and AI calls? What is the retention and deletion model per entity? Who is on call, in which hours, with which response time? How are dependency updates handled and billed? What exactly do we own at the end, and how is handover performed? What does the second year cost if we add nothing?

Answers to those six questions predict the total cost of a system far better than a day rate. If you want a structured starting point for your own project — roadmap, tech stack, and a rough specification — our blueprint generator produces one in minutes, free of charge.