Casos de éxito

Problemas reales, decisiones técnicas y el resultado que quedó tras la entrega.

22/22

Alquiler de motos de agua del anuncio al pago, en producción.

Contexto: Marketplace de dos lados: por un lado quien tiene una moto de agua parada, por el otro quien quiere el día en el agua. Son tres aplicaciones, web, iPhone y Android, sobre un único backend.
Restricción: El camino del dinero no admite ensayo: hay reparto de valor entre plataforma y propietario, fianza bloqueada en la tarjeta antes de la entrega y devolución cuando la reserva se cae.
Decisión técnica: Stripe Connect con cargo destinado y comisión de aplicación, fianza fuera de sesión y reversión de transferencia en la cancelación. El backend es Java en arquitectura hexagonal, y tanto el BFF en Next como la app en Expo consumen el mismo contrato.
Resultado: El recorrido completo se ejecutó de punta a punta contra la API real, pago y devolución incluidos, y la regla medida entre el push y el código en el aire es de catorce minutos.

2 productos

La cartera se debita antes de que salga el mensaje.

Contexto: Capa de envío y recepción entre los productos y la API oficial de Meta, con número y marca propios por cliente.
Restricción: Meta cobra por conversación. Una cola que reprocesa sin control no genera un log feo, genera una factura, y un mensaje repetido al cliente final no se deshace.
Decisión técnica: El débito en la cartera del cliente ocurre antes del envío, con idempotencia por clave y cola muerta para lo que falla de verdad. Fastify y BullMQ sobre Redis, con consola propia en Next.
Resultado: Dos productos en producción consumen el hub por clave de API, cada uno manteniendo su propia marca en la conversación con el cliente final.

sin registro

El precio que paga la hora del dueño, calculado sin cuenta.

Contexto: Brújula financiera para autónomos y pequeños negocios: la cuenta de cuánto queda de verdad, rehecha sola cuando el material sube de precio.
Restricción: Un diagnóstico que pide correo antes de mostrar el número no es diagnóstico, es captación, y pedir facturación a quien todavía no confía en el producto es pedir demasiado pronto.
Decisión técnica: Las mismas funciones de coste que corren dentro del producto se llevaron al navegador. La calculadora pública no tiene servidor, no tiene cuenta y no guarda nada. Next sobre Turso, con política de seguridad generada en cada petición.
Resultado: El visitante ve su propio número antes de decidir si quiere una cuenta.

Caso anonimizado

39 habilidades

El informe se niega a imprimir fuera de la regla.

Contexto: Evaluación funcional de la comunicación infantil, usada en consulta y entregada como informe para que la familia lo lea.
Restricción: Un informe clínico no admite nota única, barra en cero ni número que nadie midió, y hay expresiones de autoría que no pueden llegar a la impresión.
Decisión técnica: El instrumento es dato versionado, no código: la misma definición alimenta la API en Rust, el front y las pruebas. Una guarda de vocabulario corre en la fase de captura del clic y cancela la impresión cuando el texto rompe la regla.
Resultado: En uso clínico real, con traza de auditoría que impide borrar una evaluación que ya tiene historial.

60 Hz

El servidor decide, el navegador solo dibuja.

Contexto: Juego de fútbol 2D multijugador que corre en el navegador, con partida rápida, entrenamiento sin conexión y torre de duelos.
Restricción: En un juego competitivo, un cliente que calcula es un cliente que hace trampa, y el mismo código tiene que correr sin conexión, sin servidor alguno.
Decisión técnica: La simulación es determinista y vive en un paquete propio, separada del render. El servidor la ejecuta y transmite estado, y el cliente solo interpola. El modo sin conexión corre esa misma simulación dentro del navegador.
Resultado: En el aire, con partida en línea, entrenamiento sin cuenta y duelo, con la lógica de juego con una sola fuente, probada por los dos modos a la vez.