Remolk
Alquiler de trailers donde software, pagos, telemetría y operación física tienen que funcionar como un solo sistema.
Un negocio físico modelado como producto digital.
Lo interesante de Remolk no es que tenga una web. Es que clientes, reservas, pagos, trailers físicos, dispositivos GPS, telemetría, reglas de operación y decisiones de negocio tienen que comportarse como un solo sistema coherente.
Parece un alquiler simple. No lo es.
Desde afuera, alquilar un trailer parece un catálogo, una fecha y un pago. Pero el sistema real tiene que representar algo que existe en el mundo físico: un activo concreto, disponible o no, que se entrega, se mueve, vuelve y puede generar excepciones.
El producto tiene que cerrar tanto para el cliente como para quien opera el negocio. Ahí es donde el software deja de ser “pantallas” y se convierte en un sistema.
No solo “el que hace la web”.
Participo como CTO y socio. El trabajo no es solo implementar pantallas: es decidir qué sistema necesita de verdad el negocio, en qué orden construirlo y qué mueve la aguja para el negocio y para el usuario. El sistema está en producción: pagos reales, dispositivos reales y un flujo de alquiler que se puede recorrer entero.
Estuve a cargo de todo el desarrollo de Remolk de punta a punta: arquitectura, código y decisiones de producto.
El producto vive entre dos mundos.
Cada capa tiene que mantenerse alineada con la siguiente — desde la intención del cliente hasta lo que está pasando físicamente con cada activo.
El producto vive entre el estado digital y lo que está ocurriendo físicamente con cada trailer. Es una vista a nivel de sistema, no documentación de arquitectura de bajo nivel.
Las decisiones que sostienen el sistema.
El precio no lo decide el navegador
Si el monto a cobrar viaja desde el cliente, el cliente puede cambiarlo.
El servidor recalcula el precio de cero antes de generar el cobro e ignora lo que le manda el front. Suena obvio hasta que aparece la primera funcionalidad de descuento que se implementa del lado equivocado.
Un pago, un alquiler — nunca dos
La confirmación del pago puede llegar por dos caminos distintos y casi al mismo tiempo. Si los dos crean el alquiler, se duplica.
Ambos caminos convergen en la misma operación idempotente. El segundo que llega no crea nada: reconoce que el trabajo ya está hecho.
La devolución tiene que ser verificable
“Ya lo devolví” es una afirmación del usuario, y de ella depende que el trailer vuelva a estar disponible y que se corte el cobro.
La devolución exige una foto tomada en el momento, que se valida automáticamente antes de darla por buena, y el cierre se autoriza del lado del servidor. El usuario no puede liberar el activo por su cuenta. La foto se analiza automáticamente con IA para verificar que corresponda al activo antes de dar el alquiler por cerrado — IA usada donde reemplaza a alguien mirando fotos de a una, no como adorno del pitch.
El mundo físico también tiene estado.
En un producto de demo, cambiar un valor en la base de datos puede alcanzar. En Remolk, el sistema representa activos físicos reales: eso cambia cómo pensás la corrección, el estado, la visibilidad, la confiabilidad y los pagos.
Cuando un producto representa activos físicos, “lo que dice el sistema” y “lo que está pasando afuera” tienen que mantenerse alineados. Ese tipo de problema obliga a pensar más allá del frontend: estados, pagos, dispositivos, reglas y operación terminan formando parte del mismo producto.
Elegir el dispositivo también era una decisión de producto.
El sistema necesitaba que un trailer parado en la calle comunicara su estado sin que nadie tenga que preguntar: disponible, alquilado o fuera de servicio. Eso convierte algo que parece una compra en una restricción técnica — cuántas señales distintas tiene que poder emitir el equipo, y por lo tanto qué capacidades de control necesita el dispositivo.
Me hice cargo de esa punta entera: buscar proveedores, pedir y comparar cotizaciones, leer las hojas de datos, contrastar cada modelo contra lo que el producto necesitaba mostrar y negociar condiciones. La conclusión no fue “el más barato”: el equipo más económico no podía representar todos los estados que el negocio necesita distinguir, y elegirlo habría hecho imposible una funcionalidad que ya estaba decidida. Es el tipo de decisión que no se puede delegar en un proveedor: hay que leer la hoja de datos y el roadmap del producto al mismo tiempo.
Armé el prototipo del módulo de estado —caja estanca, alimentación solar y las luces— y lo validé contra un alquiler real antes de comprometer un lote.
Decidir qué construir primero.
¿Por qué mobile-first?
El alquiler se decide y se gestiona parado al lado de un trailer, desde el teléfono. El desktop existe, pero el que manda es el celular.
¿Qué entra en el MVP?
Solo el camino que permite un alquiler real de punta a punta: encontrar, pagar, retirar, usar, extender y devolver. Todo lo que no está en ese camino quedó afuera, aunque se viera bien en una demo.
¿Reservas anticipadas o alquiler inmediato?
Sin calendarios ni reservas a futuro. Se alquila lo que está disponible ahora. Un calendario promete algo que el mundo físico no siempre puede cumplir.
¿Cómo se representa la disponibilidad?
El estado del sistema y el estado real del activo tienen que coincidir: el trailer se libera cuando la devolución quedó confirmada, no cuando el usuario dice que la hizo.
De prototipo a operación real.
El próximo aprendizaje ya no viene de otra demo. Viene de usuarios, pagos y trailers reales. El sistema está funcional y la siguiente etapa es validar cómo se comporta el producto cuando entra en operación. No reclamo métricas de negocio que todavía no existen.
De flota propia a red.
Hoy Remolk alquila su propia flota. El paso siguiente cambia la naturaleza del producto: vender trailers con el sistema ya instalado. El dueño lo usa como un trailer común y, cuando no lo está usando, lo da de alta desde la web: entra al pool de Remolk, se alquila como cualquier otro y el dueño recibe una parte de lo que genera.
Eso convierte un negocio de flota —que crece comprando activos— en una red que crece cuando alguien más compra el activo. Y le cambia el peso a casi todo lo que ya está construido: la disponibilidad deja de ser un dato interno y pasa a depender de un tercero; la verificación de la devolución deja de proteger sólo a la empresa y pasa a proteger al dueño del trailer; la telemetría deja de ser una herramienta de operación y pasa a ser la evidencia con la que se le rinde cuentas a alguien que puso su propio activo.
Es la dirección, no una promesa con fecha. Lo relevante es que las decisiones de los últimos meses —el precio resuelto del lado del servidor, la devolución verificable, el estado del activo señalizado en la calle— son exactamente las que hacen que ese paso sea posible sin rehacer el sistema.
Product ownership
Convertir la operación del negocio en decisiones de producto.
Systems thinking
Entender software, pagos, dispositivos y activos físicos como un solo sistema.
Priorización
Decidir qué tiene que existir antes del uso real y qué puede esperar.
Integraciones
Trabajar alrededor de pagos y telemetría de dispositivos, no solo de UI aislada.
Criterio de negocio
Optimizar para un negocio de alquiler que funcione, no para la novedad técnica.
Restricciones reales
Construir hacia usuarios que van a pagar y activos que se mueven de verdad.
Un equipo de una persona más agentes.
Remolk se construyó con un flujo asistido por IA, de punta a punta: cada cambio nace como ticket con criterios de aceptación, lo implementa un agente, se abre un pull request con entorno de preview, pasa por una revisión automatizada que clasifica los hallazgos por severidad, se hace QA sobre el preview y recién ahí se mergea. El merge deploya a producción solo.
Mi rol ahí no es escribir cada línea: es definir qué se construye, en qué orden, qué tiene que ser cierto para aceptarlo y qué no puede romperse nunca. La parte difícil de trabajar con agentes no es que escriban código — es tener el criterio para decidir qué código merece existir y para detectar cuándo lo que hicieron está bien escrito y mal pensado.
¿Tu producto también tiene que sobrevivir fuera de la pantalla?
Pagos, personas, operación, hardware o reglas reales cambian por completo cómo hay que pensar el software.