Next.js in Spain
Next.js development services for Spanish companies
A Next.js development company working with Spanish teams. The AEPD reads cookie consent strictly, and Spanish copy runs long enough to break interfaces designed in English.
Spain gets grouped into "the EU" and treated as solved by a build that satisfies GDPR. Two things make that wrong in practice, and both of them are visible on the page rather than in a policy document.
The AEPD is stricter than the average
Spain's data protection authority has issued detailed guidance on cookie consent, and its reading is at the stricter end of what European regulators have published - particularly on whether continuing to browse can count as acceptance, and on how visible the reject option has to be.
Set against a typical Next.js build, the consequences are specific:
- Nothing non-essential loads before a decision. Not analytics, not
the tag manager that loads analytics, not the chat widget. In an App
Router application this usually means moving
<Script>out of the layout and behind a consent condition, which is a real refactor if the scripts are scattered. - Reject has to be as easy as accept. One click, same level, same visual weight. This is a design constraint with a legal tail.
- The banner cannot block content while it decides. Which, awkwardly, is also a Core Web Vitals problem - a full-screen overlay injected after hydration is one of the most reliable ways to wreck Cumulative Layout Shift. Getting consent and CLS right at the same time is mostly a question of reserving the space before the script arrives.
Spanish e-commerce also sits inside the European Accessibility Act's scope, which since 2025 has made WCAG conformance a commercial question rather than an ethical one.
Spanish copy does not fit English components
Translated Spanish runs longer than the English it came from. Not dramatically - but reliably, and by enough to matter in exactly the places interfaces are tightest: buttons, tabs, table headers, nav items, badges.
The failure is not ugly wrapping. It is a component that was given a fixed height in English, receives two lines in Spanish, and clips. Or a horizontal nav that fits six items in English and seven-and-a-half in Spanish, so the last one disappears under an overflow nobody tested.
We found this class of bug on our own site by rendering every page at seven viewport widths in a headless browser and failing the build when any element overflows its container. That check is cheap to build and it is the only method that works - reading a Spanish page in a 1440px browser window tells you nothing about what happens at 360.
If you are shipping a Spanish locale off an English design system, this is worth measuring before a customer finds it.
Where projects start
Most Spanish engagements here are commerce. That means Next.js commerce work, usually with performance engineering attached, because the consent and accessibility changes above tend to surface rendering problems that were already there.
Where there is an existing site, a fixed-price audit comes first. Where there is not, application development with the locale model decided up front - not after the English version ships.