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 — y es el mismo supuesto que está horneado en Hostaway, Guesty y Lodgify.

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 — mira alternativas a Guesty para agencias de gestión de propiedades para ver cómo es el resto del mercado.

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

Preguntas frecuentes

¿Por qué no construimos Recal sobre un channel manager existente?

Envolver un channel manager nos habría permitido lanzar en unos seis meses en vez de en dos años, pero habría obligado a adaptar nuestro flujo de trabajo al modelo de datos de otro. Un channel manager asume que una reserva es una fila en un calendario creada y confirmada en minutos, y ese supuesto no se sostiene para las propiedades de alto valor con las que trabajamos. Elegimos construir nuestro propio cimiento en lugar de pasar años parcheando limitaciones que no podríamos cambiar.

¿Qué falla en el modelo de datos del channel manager para reservas de alto valor?

Un channel manager trata la reserva como una fila contra una propiedad que existe como una unidad fija de inventario. En la práctica, una reserva en una villa cara es un ciclo de vida: 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. Además, las propiedades se reconfiguran y los propietarios bloquean sus propias fechas, nada de lo cual encaja en un modelo de fila fija.

¿Qué permite realmente construir nuestro propio cimiento?

El objeto reserva conoce su propio ciclo de vida, y 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 por ingeniería inversa. Nada de esto se ve en una demo; aparece como la ausencia de fricción meses después, porque el modelo ya lo había contemplado.

¿Qué le costó esta decisión a Recal?

El coste 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, y dedicamos más tiempo a infraestructura que no aparece en marketing. Aceptamos ese intercambio porque la alternativa era negociar cada función futura contra las primitivas de otro producto.

¿Cuál es el beneficio para las agencias que usan Recal?

Las agencias no tienen que retorcer su operación para encajar en la herramienta. Pueden llevar su negocio como funciona de verdad, y el software les sigue, en lugar de vivir en un conjunto permanente de workarounds. Ese resultado no estaba disponible como una función encima del cimiento de otro, y por eso construimos el nuestro.