La majoria del que escric aquí acaba sent un producte, o si més no alguna cosa amb pantalla de login i pàgina de preus. Però bona part de la feina que fem a Maladeta Studio no surt mai en una diapositiva bonica de portfolio, perquè no és un producte: és infraestructura. Dues de les nostres quatre àrees de treball declarades són literalment mobilitat en espais naturals i gestió de residus, i si passes prou temps en un lloc com la Vall d'Aran entens perfectament per què aquestes categories existeixen al nostre web. És una vall amb una població fixa petita que, durant part de l'hivern i un altre cop a l'estiu, ha de funcionar com un lloc molt més gran. Aquest desajust entre la capacitat normal i la realitat de temporada alta és el problema real darrere de dos dels nostres projectes — un sistema de reserva d'aparcament que internament anomenàvem aparcaran, i un projecte de gestió de residus anomenat JoRecicli — i val la pena explicar-ho amb honestedat, perquè no s'assembla gens a muntar un producte SaaS.
1. El problema: massa cotxes, una sola carretera
La Vall d'Aran és als Pirineus, al vessant atlàntic però administrativament a Espanya, connectada amb la resta de Catalunya sobretot per un únic corredor de carretera. Un dissabte bo de neu pols, o un cap de setmana d'estiu amb les rutes de senderisme i bici a tope, aquesta geografia es converteix en un coll d'ampolla: tots els cotxes baixen per la mateixa carretera cap al mateix grapat d'estacions d'esquí o capçaleres de ruta, i els aparcaments de la base s'omplen molt abans que la majoria de gent surti de casa. Sense alguna manera de gestionar-ho amb antelació, el resultat és previsible — cotxes aparcats al voral, llevaneus bloquejats, i qui estigui de guàrdia aquell dia improvisant el trànsit a mà.
Aquest és l'encàrrec real darrere de l'aplicació web de reserva d'aparcament que vam construir cap al 2021, fent servir dades reals d'aquella temporada per dimensionar-la. És una app en Next.js, i el que és interessant no és el framework, són les restriccions. No estàs dissenyant per a un trànsit estable i previsible, sinó per a una corba de demanda que es manté plana durant mesos i després es dispara amb força potser una dotzena de dies a l'any. El sistema ha de fer llegible la capacitat abans que la gent surti de casa: aquest aparcament té tantes places, tantes ja estan reservades, reserva la teva o compta amb un autobús llançadora.
- La demanda no és uniforme — es concentra en un grapat de caps de setmana punta a l'any, no en trànsit diari constant
- La capacitat tampoc és fixa — el llevaneu, les necessitats de personal i l'accés d'emergències mengen places del mateix aparcament dia a dia
- La majoria d'usuaris no són recurrents — molta gent obre l'app un cop per temporada, des d'un cotxe fred, amb guants posats
Ja no tinc al davant la lògica real de producció, però aquesta és més o menys la forma que ha de tenir qualsevol comprovació de disponibilitat — i aquesta línia de "no vendre mai el 100%" fa més feina del que sembla.
def is_slot_available(lot, date, requested_spots):
capacity = lot.capacity_for(date) # la capacitat pot variar: menys places si hi ha llevaneu o manteniment
reserved = lot.reservations_for(date).sum(spots)
walk_in_buffer = lot.reserve_for_walk_ins(date) # no vendre mai el 100% de les places online — deixar marge per a personal i emergències
return (capacity - reserved - walk_in_buffer) >= requested_spots
2. Els residus tampoc esperen la temporada alta
L'aparcament té la versió dramàtica del problema de pics estacionals perquè és visible. Els residus tenen el mateix problema de fons amb menys focus. Una vall amb una població fixa acostumada a un ritme de recollida determinat ha de fer front de cop a un volum multiplicat quan s'omplen els apartaments de lloguer i totes les bases de les estacions funcionen a tope. Aquí és on entra JoRecicli, un projecte de gestió de residus que vam fer per a un client de la vall, que al nostre web apareix sota "projectes que hem desenvolupat" i no sota "els nostres productes", cosa que ja diu que va ser feina a mida per a una institució. El raonament segueix la mateixa forma que el de l'aparcament: els calendaris fixos de recollida assumeixen una mitjana que la temporada alta trenca, així que el que pot aportar el software és substituir el "perquè toca segons el calendari" pel "perquè el contenidor està realment ple".
3. Com és la tecnologia cívica en el dia a dia
Les parts d'aquesta feina que no acaben en un cas d'estudi tenen a veure sobretot amb per a qui construeixes. Els clients públics i institucionals es mouen amb un altre rellotge que una startup — la contractació triga, les decisions passen per més d'un interlocutor, i els requisits poden canviar per raons que no tenen res a veure amb el software. Tampoc et pots permetre el luxe de "llança-ho i itera al pròxim sprint": un sistema d'aparcament per a una vall d'esquí concentra gairebé tot el seu ús real en un grapat de caps de setmana concrets, i si falla en un d'ells, no hi ha manera discreta d'arreglar-ho abans de la següent prova — la següent prova és el dissabte que ve, amb neu, i amb tothom mirant.
El que fa que valgui la pena igualment és que l'impacte és inusualment concret. No persegueixes una mètrica de creixement en un dashboard; mires si aquest gener van acabar menys cotxes aparcats al voral que l'anterior. És més lent, menys vistós, i mai tindrà un llançament a Product Hunt — però és de les proves més honestes que he trobat de si allò que construeixes és realment útil.
Res d'això és el tipus de feina que acaba en una newsletter de "startups a seguir", i em sembla bé. El que sí que em pregunto és quant del que hi ha darrere d'aparcaran i JoRecicli és específic de la Vall d'Aran i quant funcionaria, amb canvis menors, en qualsevol de les desenes de valls de muntanya d'Europa que lliuren cada hivern exactament la mateixa batalla. Mai ho hem comprovat. Potser hauríem de fer-ho.