English
العربية
Deutsch
EspañolNext.js in Madrid
Next.js development for Madrid companies
A Next.js development company working with Madrid teams. Two hours of difference, corporate and public-sector buyers, and Spanish copy that overflows components sized for English.
- Working day overlap
- Six hours or so. Madrid is two hours behind Ankara, and the Spanish day starts and finishes later, which widens the useful window rather than narrowing it
- Who buys here
- Corporates, banks, utilities and organisations that sell to the public sector
- What that changes
- Procurement and accessibility requirements arrive before the design does
- Local specifics
- Spanish runs noticeably longer than English, and the components that break are the ones sized for English
Madrid is two hours behind us, and the Spanish working day starts and finishes later than the northern European one. The two facts cancel each other out usefully: the overlap is wider than the clock suggests, because our afternoon sits inside your working day rather than at the end of it.
Who is buying
Corporates, banks, utilities, and the consultancies and product companies that sell into the public sector. That last category shapes a great deal of the work here, because selling to public bodies brings requirements that arrive before the design does - accessibility among them, and procurement always.
The practical consequence is the same as in any procurement-led market: the first week is spent finding out which approvals have the longest lead time, and the phases are ordered so that a blocked dependency stops one phase rather than the project.
Spanish breaks layouts built for English
This is the local specific that reaches the components, and it is underestimated because it looks like a content problem.
Spanish runs noticeably longer than English for the same meaning. A button labelled "Save" becomes "Guardar"; "Settings" becomes "Configuración"; "Sign out" becomes "Cerrar sesión". Each is individually fine and collectively they break a layout that was sized while looking at the English.
The failures are predictable enough to design against. Buttons whose width was set by their English label. Tab bars that wrap to a second line and push everything below them down. Table headers that no longer fit their column, so the column grows and the row overflows. And truncation applied to a string whose meaning lives at the end, so what remains is the half that says nothing.
The fix is not a clever CSS trick. It is rendering the Spanish version at the narrow widths and looking at it, which is the only way anyone finds these. We run that as a check rather than as a review step, because a layout that was correct last month is not necessarily correct after a label changed.
Which routes are public matters more here
A good share of Madrid work has a public surface and an authenticated one in the same application - a public catalogue, tariff information or service pages, plus a logged-in area for customers.
Those two want opposite rendering strategies, and the common failure is that the authenticated side quietly drags the public side with it. A cookie read in a shared layout opts every page underneath out of static rendering, including the pages that should be served from a cache in Madrid rather than rendered per request from somewhere else.
That is a rendering decision rather than a default, and it is the first thing worth measuring on an existing application here.
Commercially
Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in euros, by bank transfer, with no Turkish VAT because exported services are exempt. Scope agreed in writing before work starts and priced per project.
The country-level ground - consent as the regulator reads it, invoicing requirements, the regional layer inside Spain - is on the Spain market page.