Desarrollo de software a medida con Next.js

El software a medida es software que existe porque una empresa hace algo concreto y ningún producto modela ese algo con suficiente precisión como para merecer que lo fuercen.

Esa es toda la definición, y es también lo primero que conviene comprobar. Buena parte de lo que se encarga como software a medida es un producto con el logotipo cambiado, y buena parte de lo que se compra como producto acaba siendo software a medida de todos modos tras dos años de apaños. Las dos cosas son caras y las dos se evitan en la primera conversación.

Qué significa esto en la práctica

El trabajo casi siempre tiene una de tres formas.

Un sistema operativo - aquello dentro de lo que un equipo trabaja todo el día. Presupuestos, trabajos, casos, stock, calendarios, aprobaciones. Suele sustituir a un conjunto de hojas de cálculo, a una aplicación heredada que nadie puede cambiar, o a las dos cosas a la vez.

Una superficie para clientes sobre sistemas que nunca se diseñaron para tener una. Un portal, una página de seguimiento, una cuenta de autoservicio, una reserva. La parte difícil rara vez es la pantalla; es que los datos de detrás viven en algo antiguo y responden despacio.

Una herramienta interna que existe porque un producto no sabe hacer la única cosa que importa. Son los proyectos más pequeños y a menudo los de mayor retorno, porque la alternativa es la semana de alguien.

Por qué renderizado en servidor y no una aplicación de una sola página

Durante años una aplicación de navegador significaba construir tres cosas: un front end, una API que lo alimentara, y el pegamento entre ambos. Una parte grande del código de esos sistemas existía solo para mover datos entre dos partes de la misma aplicación.

Una aplicación con App Router elimina esa capa en la mayoría de las pantallas. El servidor lee los datos y renderiza la página. El navegador recibe marcado en vez de un bundle que después pide los datos que necesita. El JavaScript se envía solo donde una interacción lo exige de verdad, y en un sistema operativo eso es una minoría de las pantallas.

Los efectos son poco espectaculares y se acumulan. Un lenguaje en toda la aplicación en vez de dos. Un repositorio y un despliegue en vez de dos que versionan por separado. Una página que es correcta cuando llega en vez de correcta un instante después. Y bastante menos código, que es la única forma fiable de abaratar el segundo año.

Qué ruta se renderiza de qué manera sigue siendo una decisión y no un valor por defecto, y es la primera conversación de arquitectura de cada construcción. El modelo de renderizado explica lo que cuesta cada opción.

Dónde viven los datos se decide al mismo tiempo

Una aplicación a medida es sobre todo un modelo de datos con pantallas encima, así que el esquema no es un detalle para dejar para después.

Lo caro de revertir son las decisiones corrientes. Qué es una entidad y qué es un campo. Dónde se guardan el dinero y las fechas, y en qué tipo. Si un registro se puede borrar o solo sustituir. Si un estado es una columna o un historial de transiciones - que es la diferencia entre un sistema capaz de decir qué pasó y uno que solo describe el presente.

PostgreSQL es el valor por defecto en estas construcciones, por los motivos que están en la página de PostgreSQL. Es un valor por defecto y no una regla, y la única trampa operativa real - el número de conexiones bajo un entorno serverless - es un problema conocido con una respuesta conocida y no una sorpresa.

Cómo se desarrolla el proyecto

Por fases, y cada una termina con algo desplegado.

La primera fase es pequeña a propósito. Coge el corte más estrecho que sirva de verdad - un flujo completo de principio a fin en vez del esqueleto de cinco - y lo pone delante de la gente que lo va a usar. Eso hace dos cosas: decide la arquitectura contra datos reales en vez de contra un documento, y da a todo el mundo una base honesta para estimar el resto.

El alcance de cada fase se fija por escrito antes de empezarla. Tus desarrolladores revisan pull requests desde la primera semana si los tienes, porque así se transfieren las convenciones y es la única versión en la que el código sigue siendo mantenible después de que nos vayamos.

Qué recibes

Al final de cada fase, una aplicación desplegada que puedes usar - no un entorno de demostración ni una rama.

Con ella: el repositorio, con el historial de git intacto y sin depender de nosotros para construirlo o desplegarlo. Una nota de arquitectura que dice qué ruta se renderiza de qué manera, dónde está la frontera del cliente y por qué, escrita mientras se tomaban las decisiones y no reconstruida después. Las migraciones de base de datos como código, para que el esquema tenga un historial y no solo un estado actual. Un despliegue que funcione en infraestructura que controles si eso es un requisito. Y una lista de lo que no hicimos, con el razonamiento, porque lo que se deja fuera a propósito es la parte que una entrega suele perder.

Cuándo este no es el proyecto adecuado

Conviene decirlo claro, porque a veces la respuesta es no.

Si existe un producto que hace el ochenta por ciento de lo que necesitas y el veinte restante es gusto y no proceso, compra el producto. Configurar es más barato que programar y lo sigue siendo cada año.

Si lo que hace falta son unas pocas páginas y un formulario de contacto, eso es una web. Un gestor de contenidos con buenas plantillas te servirá mejor que una aplicación sin presupuesto de mantenimiento detrás.

Si el proceso todavía se está inventando, el software congelará una decisión que nadie ha tomado. Llévalo a mano o en una hoja de cálculo hasta que la forma deje de moverse, y automatiza entonces la forma que sobrevivió.

Y si nadie dentro es dueño del resultado - ninguna persona cuyo trabajo mejore cuando funcione -, se abandonará por bien construido que esté. Ese es el fallo que vemos más a menudo y el único que no tiene nada que ver con la ingeniería.