La mayoría de lo que escribo aquí acaba siendo un producto, o al menos algo con pantalla de login y página de precios. Pero buena parte del trabajo que hacemos en Maladeta Studio no aparece nunca en una diapositiva bonita de portfolio, porque no es un producto: es infraestructura. Dos de nuestras cuatro áreas de trabajo declaradas son literalmente movilidad en espacios naturales y gestión de residuos, y si pasas suficiente tiempo en un sitio como el Valle de Arán entiendes perfectamente por qué esas categorías existen en nuestra web. Es un valle con una población fija pequeña que, durante parte del invierno y otra vez en verano, tiene que funcionar como un lugar mucho más grande. Ese desajuste entre la capacidad normal y la realidad de temporada alta es el problema real detrás de dos de nuestros proyectos — un sistema de reserva de aparcamiento que internamente llamábamos aparcaran, y un proyecto de gestión de residuos llamado JoRecicli — y merece la pena contarlo con honestidad, porque no se parece en nada a montar un producto SaaS.
1. El problema: demasiados coches, una sola carretera
El Valle de Arán está en el Pirineo, en la vertiente atlántica pero administrativamente en España, conectado con el resto de Cataluña sobre todo por un único corredor de carretera. Un sábado bueno de nieve polvo, o un fin de semana de verano con las rutas de senderismo y bici a tope, esa geografía se convierte en un cuello de botella: todos los coches bajan por la misma carretera hacia el mismo puñado de estaciones de esquí o cabeceras de ruta, y los aparcamientos de la base se llenan mucho antes de que la mayoría de la gente salga de casa. Sin alguna forma de gestionar eso con antelación, el resultado es previsible — coches aparcados en el arcén, quitanieves bloqueados, y quien esté de guardia ese día improvisando el tráfico a mano.
Ese es el encargo real detrás de la aplicación web de reserva de aparcamiento que construimos hacia 2021, usando datos reales de esa temporada para dimensionarla. Es una app en Next.js, y lo interesante no es el framework, son las restricciones. No estás diseñando para un tráfico estable y predecible, sino para una curva de demanda que se mantiene plana durante meses y luego se dispara con fuerza en quizá una docena de días al año. El sistema tiene que hacer legible la capacidad antes de que la gente salga de casa: este aparcamiento tiene tantas plazas, tantas ya están reservadas, reserva la tuya o cuenta con un autobús lanzadera.
- La demanda no es uniforme — se concentra en un puñado de fines de semana punta al año, no en tráfico diario constante
- La capacidad tampoco es fija — el quitanieves, las necesidades de personal y el acceso de emergencias comen plazas del mismo aparcamiento día a día
- La mayoría de usuarios no son recurrentes — mucha gente abre la app una vez por temporada, desde un coche frío, con guantes puestos
Ya no tengo delante la lógica real de producción, pero esta es más o menos la forma que tiene que tener cualquier comprobación de disponibilidad — y esa línea de "nunca vender el 100%" hace más trabajo del que parece.
def is_slot_available(lot, date, requested_spots):
capacity = lot.capacity_for(date) # la capacidad puede variar: menos plazas si hay quitanieves o mantenimiento
reserved = lot.reservations_for(date).sum(spots)
walk_in_buffer = lot.reserve_for_walk_ins(date) # nunca vender el 100% de las plazas online — dejar margen para personal y emergencias
return (capacity - reserved - walk_in_buffer) >= requested_spots
2. Los residuos tampoco esperan a la temporada alta
El aparcamiento tiene la versión dramática del problema de picos estacionales porque es visible. Los residuos tienen el mismo problema de fondo con menos foco. Un valle cuya población fija está acostumbrada a un ritmo de recogida determinado tiene que lidiar de golpe con un volumen multiplicado en cuanto se llenan los apartamentos de alquiler y todas las bases de las estaciones funcionan a tope. Ahí es donde entra JoRecicli, un proyecto de gestión de residuos que hicimos para un cliente del valle, y que en nuestra web aparece bajo "proyectos que hemos desarrollado" y no bajo "nuestros productos", lo que ya te dice que fue trabajo a medida para una institución. El razonamiento sigue la misma forma que el del aparcamiento: los calendarios fijos de recogida asumen una media que la temporada alta rompe, así que lo útil que puede aportar el software es sustituir el "porque toca según el calendario" por el "porque el contenedor está realmente lleno".
3. Cómo es la tecnología cívica en el día a día
Las partes de este trabajo que no acaban en un caso de estudio tienen que ver sobre todo con para quién construyes. Los clientes públicos e institucionales se mueven con otro reloj que una startup — la contratación lleva tiempo, las decisiones pasan por más de un interlocutor, y los requisitos pueden cambiar por razones que no tienen nada que ver con el software. Tampoco te puedes permitir el lujo de "lánzalo e itera en el próximo sprint": un sistema de aparcamiento para un valle de esquí concentra casi todo su uso real en un puñado de fines de semana concretos, y si falla en uno de ellos, no hay forma discreta de arreglarlo antes de la siguiente prueba — la siguiente prueba es el sábado que viene, con nieve, y con todo el mundo mirando.
Lo que hace que merezca la pena de todos modos es que el impacto es inusualmente concreto. No persigues una métrica de crecimiento en un dashboard; miras si este enero acabaron menos coches aparcados en el arcén que el anterior. Es más lento, menos vistoso, y nunca tendrá un lanzamiento en Product Hunt — pero es de las pruebas más honestas que he encontrado de si algo que construyes es realmente útil.
Nada de esto es el tipo de trabajo que acaba en una newsletter de "startups a seguir", y me parece bien. Lo que sí me pregunto es cuánto de lo que hay detrás de aparcaran y JoRecicli es específico del Valle de Arán y cuánto de ello funcionaría, con cambios menores, en cualquiera de las docenas de valles de montaña en Europa que libran cada invierno exactamente la misma batalla. Nunca lo hemos comprobado. Igual deberíamos.