Problema
Tropipay necesitaba lanzar una billetera multimoneda lista para producción para una subsidiaria nueva con un plazo duro: treinta días desde el kickoff hasta la primera transacción en vivo. El producto tenía que soportar operaciones en USD, EUR y cripto, con un flujo de onboarding KYC regulado y la confiabilidad operacional que los eventos financieros demandan. Había dos ingenieros disponibles, incluyéndome, más un project manager.
El desafío no era elegir un stack. Era decidir qué NO construir dentro del deadline — y qué forma necesitaba el sistema para que lo que sí enviáramos no tuviera que ser derribado después.
Enfoque
Elegimos un monorepo Turborepo con backend en Nest.js y frontend en Next.js, compartiendo tipos de TypeScript entre los dos. La decisión que más importó no fue el framework — fue mover la superficie de notificaciones en tiempo real a Next.js Server Actions con UI optimista, en vez de levantar una infraestructura completa de WebSockets bajo el deadline.
Esa decisión no era obvia: la mayoría de los equipos por costumbre van a Socket.io para “real-time”. Para nuestro scope — eventos financieros que el usuario ya está mirando — Server Actions con actualizaciones optimistas y revalidation nos dio una superficie funcional en una semana y cero carga operacional después. WebSockets nos hubieran costado dos días de setup y un año de mantenimiento.
El onboarding KYC era un formulario multi-paso con ramas condicionales por tipo de documento de identidad. Lo construimos como una state machine en el frontend (XState) respaldada por una única entidad de sesión resumible en PostgreSQL, así un usuario que abandonara en el paso 4 podía retomar en el paso 4, no arrancar de cero.
Resultado
Lanzamos en el día 28, dos días antes del deadline. La superficie de notificaciones lleva meses en producción sin un solo page. La tasa de drop-off del KYC quedó por debajo de la estimación del equipo pre-lanzamiento, y la state machine de onboarding absorbió tres feature additions sin breaking changes.
La decisión arquitectónica de Server Actions se sostuvo: nunca tuvimos que revisitarla. Esa es la prueba de una buena decisión arquitectónica — no si es ingeniosa, sino si se mantiene fuera del camino después del lanzamiento.
