Next.js en Madrid
Desarrollo Next.js para empresas de Madrid
Una agencia de desarrollo Next.js que trabaja con equipos de Madrid. Dos horas de diferencia, clientes corporativos y del sector público, y un español que desborda componentes dimensionados en inglés.
- Solape de jornada
- Unas seis horas. Madrid está dos horas por detrás de Ankara, y la jornada española empieza y acaba más tarde, lo que ensancha la ventana útil en lugar de estrecharla
- Quién compra aquí
- Corporaciones, banca, utilities y empresas que venden al sector público
- Qué cambia eso
- Las compras y los requisitos de accesibilidad llegan antes que el diseño
- Particularidades locales
- El español es bastante más largo que el inglés, y los componentes que se rompen son los dimensionados en inglés
Madrid está dos horas por detrás de nosotros, y la jornada española empieza y acaba más tarde que la del norte de Europa. Los dos hechos se compensan de forma útil: el solape es más amplio de lo que indica el reloj, porque nuestra tarde cae dentro de su jornada en lugar de al final de ella.
Quién compra
Corporaciones, banca, utilities, y las consultoras y empresas de producto que venden al sector público. Esa última categoría marca buena parte del trabajo aquí, porque vender a organismos públicos trae requisitos que llegan antes que el diseño: accesibilidad entre ellos, y compras siempre.
La consecuencia práctica es la misma que en cualquier mercado dirigido por compras: la primera semana se dedica a averiguar qué aprobaciones tienen el plazo más largo, y las fases se ordenan para que una dependencia bloqueada detenga una fase y no el proyecto.
El español rompe diseños hechos en inglés
Esta es la particularidad local que llega hasta los componentes, y se subestima porque parece un problema de contenido.
El español es bastante más largo que el inglés para decir lo mismo. Un botón que pone "Save" pasa a "Guardar"; "Settings" pasa a "Configuración"; "Sign out" pasa a "Cerrar sesión". Cada uno por separado está bien, y juntos rompen un diseño que se dimensionó mirando el inglés.
Los fallos son lo bastante predecibles como para diseñar contra ellos. Botones cuyo ancho lo fijó su etiqueta inglesa. Pestañas que saltan a una segunda línea y empujan hacia abajo todo lo que viene después. Encabezados de tabla que ya no caben, así que la columna crece y la fila desborda. Y truncados aplicados a una cadena cuyo significado está al final, de modo que lo que queda es la mitad que no dice nada.
El arreglo no es un truco de CSS. Es renderizar la versión en español a anchos estrechos y mirarla, que es la única forma en que alguien encuentra esto. Nosotros lo ejecutamos como una comprobación automática y no como un paso de revisión, porque un diseño que era correcto el mes pasado no lo es necesariamente después de cambiar una etiqueta.
Qué rutas son públicas importa más aquí
Buena parte del trabajo madrileño tiene una superficie pública y otra autenticada en la misma aplicación: un catálogo público, información de tarifas o páginas de servicio, más un área de cliente.
Esas dos quieren estrategias de renderizado opuestas, y el fallo habitual es que el lado autenticado arrastra discretamente al público. Una lectura de cookie en un layout compartido deja fuera del renderizado estático a todas las páginas que cuelgan de él, incluidas las que deberían servirse desde una caché en Madrid en lugar de renderizarse por petición desde otro sitio.
Eso es una decisión de renderizado y no un valor por defecto, y es lo primero que merece medirse en una aplicación existente.
En lo comercial
La factura la emite Codefacture Yazılım A.Ş., con domicilio en Türkiye, en euros y por transferencia bancaria, sin IVA turco por la exención de servicios exportados. El alcance se cierra por escrito antes de empezar y se presupuesta por proyecto.
El terreno de ámbito nacional - el consentimiento tal como lo lee el regulador, los requisitos de facturación, la capa regional dentro de España - está en la página de España.
