La decisión de arquitectura cara suele ser una reescritura que nadie necesitaba. Una tienda que ya toma pedidos en WordPress no se vuelve más segura porque la portada pase a un framework más nuevo. Un producto que es sobre todo una API y un tablero no se vuelve más claro porque lo meta a la fuerza en el mismo tema que la tienda. Elijo el stack que ya sostiene el comportamiento, y mantengo el borde lo bastante nítido para que una persona todavía pueda ver al otro lado.
Quédate donde el negocio ya vive
Si el ingreso es un pago de WooCommerce, el trabajo pertenece al lado de ese pago: el tema, los plugins en los que de verdad confío, el servidor, el correo, las copias. Mover el catálogo a un frontend aparte para que el stack parezca actual es un proyecto. No es, por sí solo, un arreglo para un código promocional o un webhook perdido. Tengo más paciencia para un cambio sencillo en PHP que sale esta semana que para una migración cuyo premio es estético.
Laravel se gana su sitio cuando la cosa es una aplicación con sus propias reglas, sus propias colas y su propia administración, y no debe doblarse en páginas. Un canal de contenido con un tope de gasto y un paso de aprobación humana es esa clase de aplicación. Un sitio de marketing no lo es.
| El sistema ya es | Echo mano de | No echo mano de |
|---|---|---|
| Una tienda que toma pedidos | WordPress, WooCommerce y el servidor alrededor | Una reescritura para que la portada sea otro framework |
| Una aplicación con colas y un admin | Laravel, o Nest si el resto de ese producto ya es TypeScript | Un montón de plugins que se hacen pasar por un producto |
| Una interfaz tipada compartida por un tablero y una API | TypeScript, de punta a punta | Un segundo lenguaje solo para los botones |
| Recuperación, puntuación, un servicio pequeño sobre documentos | Python | El runtime PHP de la tienda, por lealtad |
Un lenguaje a lo largo de un producto, no de una carrera
Dentro de un producto quiero un idioma principal, para que un cambio en la API y un cambio en la pantalla sean la misma revisión. A lo largo de mi trabajo no finjo que todo sea un solo idioma. PHP, TypeScript y Python están todos en producción aquí, a propósito. El error es mezclarlos dentro de un solo camino de petición porque cada capa fue la preferencia de alguien.
PostgreSQL cuando los datos tienen relaciones y quiero que la base las haga cumplir. MySQL cuando eso es lo que la tienda ya corre y moverlo no es la tarea. Redis para una cola o una caché, no como segunda fuente de verdad. Docker y un nginx aburrido cuando el despliegue hay que describirlo, no cuando me apetece aprender un orquestador.
Una reescritura tiene que nombrar el incidente que quita
Pido una frase antes de que un framework nuevo entre en el plan. Qué incidente, que el stack actual no puede cerrar, desaparece por el traslado? Si la frase trata de gusto, de contratar o de una charla de conferencia, el traslado espera. Si la frase es “el plugin de pago no puede expresar esta regla de precio, y ya lo he parcheado dos veces”, esa es una frase real, y aun así busco un parche más pequeño antes de un escaparate nuevo. El parche más pequeño suele estar ahí.
La misma prueba vale para un servicio que me tienta añadir junto a la tienda. Una cola se justifica cuando una petición tiene que sobrevivir a un reintento. Un frontend aparte se justifica cuando dos clientes, no un desarrollador, necesitan la misma API. Una base nueva casi nunca se justifica en el mismo trimestre que un problema de fiabilidad. Los datos que ya tienes son el sistema. Moverlos es un proyecto propio, con su propio inventario, y no arregla el código promocional.
Puedo sostener una tienda y un servicio al lado porque se encuentran en un borde documentado: un webhook, una cola, una tabla. No puedo sostener un sistema cuyos bordes son “pregunta a quien construyó esa parte”. Esa persona tengo que ser yo, también después del lanzamiento. Así que una herramienta nueva tiene que pagar alquiler. Si no quita un traspaso o una clase de incidente, es gusto, y el gusto puede esperar.
Elige el stack que deja el siguiente incidente dentro de una sola cabeza. La novedad tiene que ganar a eso, no al revés.
