Construye primero el calendario y después el cobro

En enero le pedí a un programador que dejara de trabajar en los pagos.

Sí, en los pagos. Lo que trae el dinero.

Te cuento.

Estábamos construyendo nuestro motor de reservas en los ratos libres. Entre semana, trabajo para clientes. Los fines de semana, un programador externo que nos dedicaba los suyos. No teníamos un equipo de producto. Teníamos sábados y domingos prestados.

En su lista había dos cosas. La sincronización de calendarios, para que la disponibilidad de un alojamiento fuera la misma en todas las plataformas donde se vende. Y el cobro con tarjeta a través del TPV virtual del banco.

El cobro nos estaba dando guerra. Mucha. Y al final, el problema no era el código.

Era el certificado.

Horas revisando código para descubrir que el fallo estaba en la capa más aburrida de todas. Como buscar las llaves por toda la casa y encontrarlas puestas en la puerta.

Lo que suena importante y lo que lo es

Lo fácil habría sido apretar con los pagos. Es la función «de verdad», la que suena bien en una reunión comercial: «¿Los clientes pueden pagar online?».

Pero mientras tanto, a mediados de enero, el motor de reservas de una masía rural ya estaba listo y conectado a una de las grandes plataformas de reservas. Solo faltaba enseñárselo al propietario y ponerlo en marcha.

Y ahí es cuando un motor de reservas deja de ser una función de la web y pasa a ser infraestructura.

Si alguien reserva en la plataforma, esa fecha se cierra en la web del propietario. Si alguien reserva directamente, la plataforma se entera. Cuando eso falla, no pierdes un pago. Tienes a dos familias con las maletas delante de la misma habitación.

Un problema con los pagos tiene apaños: pides una transferencia o cobras a la llegada. Es un engorro, pero nadie se queda sin vacaciones.

Una reserva doble no tiene apaño. Es una llamada que nadie quiere hacer.

Así que le pedí que aparcara los pagos y se centrara en los calendarios.

Construye primero la parte que más duele cuando falla, no la que mejor queda en una demo.

La culpa era mía

Hasta que lo dije claramente, él tenía las dos cosas para el mismo fin de semana. Normal: nadie le había dicho cuál iba primero.

Cuando alguien te regala sus fines de semana, marcar las prioridades es trabajo tuyo, no suyo. Dos funciones a medias valen menos que una terminada.

Y los clientes piden lo que pueden imaginar. Nadie se imagina un fallo de sincronización hasta que le pasa. Mi trabajo es imaginármelo antes que ellos.

Los pagos tienen que funcionar, sí. Pero pueden ser manuales durante una temporada. Los calendarios, no: nadie puede sincronizarlos a mano en tiempo real.

Cuando nadie te financia, esto no es un detalle. Los servicios pagan el producto, y eso solo funciona si cada hora de producto va a lo más importante. No puedes hacerlo todo a la vez. El orden es la estrategia.

Le pedí que dejara de trabajar en lo que trae el dinero.

Porque un calendario lleno con cobros manuales es una molestia. Un calendario roto es un desastre.

P. D.: Antes de tocar una sola línea de código, revisa el certificado. Te lo digo por experiencia, y por unos cuantos fines de semana ajenos.