Por qué no construimos Recal sobre un channel manager existente

Cuando empezamos a construir Recal, lo racional era envolver un channel manager existente y poner nuestra interfaz por encima. La capa de sincronización de canales es un problema resuelto; las integraciones son sucias pero están documentadas; podríamos haber lanzado en seis meses en vez de en dos años. Varias personas a las que respetamos nos dijeron que íbamos a lamentar no hacerlo.

No lo hicimos, y esta es la razón.

Un channel manager se construye en torno a un supuesto concreto: que una reserva es una fila en un calendario, creada y confirmada en minutos, contra una propiedad que existe como una unidad fija de inventario. Ese supuesto es cierto para apartamentos turísticos en centros urbanos. En la práctica, es falso para las villas con las que trabajamos.

Una reserva en una villa de 30.000 € es una conversación. Empieza como una consulta, se convierte en una opción, pasa por un contrato, recibe una señal, se completa el pago, y entonces se convierte en un huésped. Los propietarios bloquean semanas para uso propio, a veces con años de antelación, a veces la mañana de la llegada. Las propiedades se reconfiguran — el cuatro dormitorios que se vuelve un cinco para un único mes pico abriendo el anexo, la villa que pierde un dormitorio a mitad de temporada por reforma. Las reservas no son filas. Son objetos con ciclo de vida.

Si hubiéramos construido sobre un channel manager, habríamos pasado los siguientes cinco años adaptando el flujo de trabajo en torno al modelo de datos subyacente — parcheando, sorteando limitaciones, escondiendo carencias detrás de trucos de interfaz. Cada función que lanzáramos habría sido negociada contra las primitivas del channel manager. Hemos visto a varios competidores tomar esa ruta. La superficie del producto se vuelve gradualmente más elaborada; el modelo de fondo sigue siendo inflexible; y las agencias a las que venden pasan su vida en workarounds.

La versión de Recal con la que acabamos es distinta. El objeto reserva conoce su propio ciclo de vida. El objeto propiedad puede reconfigurarse sin invalidar su historial. La liquidación al propietario es un artefacto de primera clase construido sobre los datos de origen, no un informe generado haciendo ingeniería inversa sobre ellos. Nada de esto es una función que se vea en una demo. Aparece en la ausencia de fricción seis meses después — la cosa con la que no tienes que pelearte porque el modelo ya la contemplaba.

El coste de construir así es real. Lanzamos más tarde de lo que habríamos podido. La primera versión fue menos completa, en funciones, que un channel manager envuelto. Hemos dedicado más tiempo a infraestructura que no aparece en marketing.

El beneficio, el que justifica el coste: las agencias boutique de villas que usan Recal no tienen que retorcer su operación para encajar en nuestra herramienta. Pueden llevar su negocio como funciona de verdad, y el software les sigue. Ese es el producto que nos propusimos construir, y no estaba disponible como una función encima del cimiento de otro.

Somos un equipo pequeño. Nos equivocaremos en muchas cosas. Pero en esta parte no, porque ya la hemos pagado.