EnglishLaravel in Germany
Laravel development services in Germany
What building a Laravel application for the German market changes - data protection that reaches the schema, invoicing with a format attached, and hosting decided before the first migration.
Most of what changes for a German build is not language. It is that several things a team would normally treat as policy have to be enforced by the application, and therefore have to be in the schema before there is data in it.
Deletion is a feature, not a promise
Article 17 gives a person the right to have their data erased. In an application that was not designed for it, honouring that request means a developer writing ad-hoc SQL across eleven tables, hoping they found all of them, and having no way to prove afterwards that they did.
Designed for it, it is a documented operation: a cascade defined in the schema, a job that runs it, an audit record that says it happened, and an explicit list of what is retained anyway because commercial or tax law requires it. That list matters - invoices generally survive an erasure request, and an application that deletes them has created a different legal problem.
The same applies to export. Article 20 asks for the data in a portable form, and an application that cannot produce it without a developer writing a query is one where every request costs an engineering day.
Consent has to be recorded, not assumed
A boolean column set to true is not a consent record. What is defensible is
when it was given, what the person was shown at the time, and what happened
when they withdrew it - which means a table with a history rather than a flag on
a user row.
This is a five-minute decision at design time and a migration with backfilled guesswork afterwards.
Invoicing has a format
Germany's move to mandatory electronic invoicing between businesses means an invoice is a structured document - XRechnung or ZUGFeRD - not a PDF that looks like one. If your application issues invoices, that is a generation and validation requirement inside the system, with an archive obligation attached to it.
The part teams underestimate is the archive: retention periods measured in years, in a form that remains readable and verifiable, which is a storage and migration concern rather than a rendering one.
Hosting, decided early
The GDPR question is about transfers rather than borders, and the EEA is a single area for that purpose - so "must it be in Germany" is usually the wrong question. The right ones are which sub-processors your provider uses, where support staff access the data from, and whether any contract you have signed imposes something stricter than the law does.
Public-sector work and several regulated sectors do impose residency. It is cheap to design for and expensive to retrofit, so it belongs in the first conversation rather than the security review.
What we do here
The same application development, database and performance work we do anywhere, with these constraints treated as schema decisions rather than as a compliance review at the end.
Engagements run in English. Documentation is written, because a written deliverable is the one your DPO, your auditor and your next developer can all read.
Procurement here asks the framework question more than anywhere else we work, usually with Symfony on the other side. The honest comparison is narrower than either community suggests, and for a team already running Symfony well the answer is often to stay.
How the invoicing works. Euros, by bank transfer to an IBAN. The invoice comes from Codefacture Yazılım A.Ş., a Turkish company, and carries no Turkish VAT, because exported services are exempt. What your finance team does with it on their side is their call.