Next.js
Webs y paneles: páginas generadas en compilación cuando se puede, servidor solo cuando hace falta.
Tecnología
Por qué construimos con React, Next y Node
No por moda ni por desprecio a nada. Por cómo se comporta cada opción cuando el proyecto crece, cuando hay que mantenerlo dos años y cuando alguien intenta atacarlo.
Comparativa honesta
| React / Next.js + Node | PHP a medida | CMS (WordPress y similares) | LMS (Moodle y similares) | |
|---|---|---|---|---|
| Rendimiento | HTML generado en compilación y servido estático; la interacción no recarga la página. | Bueno si se cuida; cada página se genera en cada visita salvo que se añada caché. | Depende de la plantilla y de los plugins. Es normal acabar con cachés encima de cachés. | Pesado por diseño: hace muchas cosas para muchos roles. |
| Superficie de ataque | Sitio estático: no hay base de datos ni panel que atacar. En la parte de servidor, solo el código propio. | La que tú escribas. Depende por completo de la disciplina del equipo. | Núcleo + tema + cada plugin, cada uno con su ritmo de parches. La mayoría de incidentes vienen de ahí. | Grande, y con datos personales de alumnos dentro. Obliga a actualizar sí o sí. |
| Coste a medio plazo | Arranque rápido con agentes de IA y poco mantenimiento después. | Barato de arrancar, caro si nadie documenta. | Muy barato de arrancar; el coste aparece en licencias de plugins y en actualizaciones que rompen cosas. | Bajo si te vale tal cual; alto en cuanto hay que personalizarlo. |
| Experiencia de usuario | Aplicaciones con estado, tiempo real y transiciones sin recargas. | Correcta para webs clásicas; el tiempo real hay que montarlo aparte. | Excelente para publicar contenido; limitada para flujos de trabajo propios. | Pensada para cursos, no para tu proceso de negocio. |
| SEO técnico | HTML completo desde el primer byte, metadatos y datos estructurados por página. | Bueno; hay que escribirlo todo a mano. | Muy bueno de serie, con plugins maduros. | Irrelevante: el contenido suele estar detrás de un login. |
| Quién lo mantiene | Un equipo que sepa JavaScript. Es el requisito real. | Fácil de encontrar, mucha variación de calidad. | Cualquiera puede publicar sin tocar código. Esa es su gran ventaja. | Administradores formados en la plataforma. |
Seamos honestos
Cuándo NO deberías contratarnos
Si tu web es un blog, una tienda estándar o una web corporativa que van a actualizar personas sin perfil técnico, un CMS es la respuesta correcta y además la barata. Lo mismo con un LMS: si necesitas cursos, matrículas, notas y certificados de la manera habitual, Moodle lleva veinte años resolviéndolo y no tiene sentido reescribirlo.
- Necesitas publicar contenido a diario sin depender de nadie: CMS.
- Quieres una tienda estándar con pasarela y transportistas ya integrados: plataforma de comercio.
- Das cursos con el flujo clásico de matrícula, evaluación y certificado: LMS.
- Tienes procesos propios, integraciones con tus sistemas, tiempo real o volumen serio: ahí entramos nosotros.
Lo que usamos
Y para qué usamos cada cosa
React
Interfaces con estado, tiempo real y componentes reutilizables entre proyectos.
Angular
Aplicaciones internas grandes de equipos que ya trabajan así: estructura fuerte y convenciones claras.
Node.js
APIs, procesos en segundo plano y tiempo real con sockets, en el mismo lenguaje que el navegador.
Kotlin
Android nativo, cuando hace falta voz, notificaciones de verdad o acceso al sistema.
Mongo y SQL
Documental para lo que cambia de forma, relacional para lo que tiene que cuadrar.
Preguntas frecuentes
Lo que nos preguntan siempre
¿WordPress es inseguro?
El núcleo de WordPress está bien mantenido. El problema típico no es el núcleo, son los complementos: cada uno es código de un tercero con su propio ritmo de actualizaciones, y basta con que uno se quede atrás. Si se usa, hay que tratarlo como lo que es: una aplicación viva que necesita actualizaciones y copias de seguridad, no una web que se deja ahí y ya.
¿Una web hecha a medida es más lenta de hacer?
Con nosotros, no. Trabajamos con agentes de IA que escriben el código, lo prueban y lo despliegan, así que el arranque se mide en días, como montar un CMS con una plantilla. Esta misma web se hizo así. La diferencia viene después: cuando hace falta algo que la plantilla no contempla, en un CMS toca pelearse con el sistema y en código propio basta con escribirlo.
¿Por qué un sitio estático para esta misma web?
Porque no necesita servidor: son ficheros. No hay proceso que reiniciar ni base de datos que asegurar, se puede servir desde cualquier sitio, aguanta cualquier pico de visitas y la superficie de ataque es prácticamente nula. Si algún día hace falta lógica de servidor, el mismo código puede pasar a funcionar con servidor sin reescribirlo.
¿Y si mañana queremos cambiar de empresa?
El código es tuyo y está en un repositorio con su historial, con despliegue automático y documentación. La tecnología es estándar y hay mucha gente que la conoce: no es un formato propietario que solo entendamos nosotros.
¿Usáis IA para escribir el código?
Sí, y no lo escondemos: esta misma web la ha construido nuestro asistente. Lo que no cambia es la revisión: todo pasa por rama, merge request y despliegue con vuelta atrás. La IA acelera el trabajo; no sustituye a quien responde de él.
¿Hablamos de tu caso?
Te decimos con franqueza si te conviene lo que hacemos o no.