Most of what I write about here ends up being a product, or at least something with a login screen and a pricing page. But a good chunk of the work we do at Maladeta Studio never shows up in a nice portfolio slide, because it isn't a product at all — it's infrastructure. Two of our four declared areas of work are literally mobility in natural spaces and waste management, and if you spend enough time in a place like Val d'Aran you understand exactly why those categories exist on our site. This is a valley with a small permanent population that, for part of the winter and again in summer, effectively has to run like a much bigger place. That mismatch between normal capacity and peak-season reality is the actual problem behind two of our projects — a parking reservation system we called aparcaran internally, and a waste-management project called JoRecicli — and it's worth talking about honestly, because it looks nothing like building a SaaS product.
1. The problem: too many cars, one road in
Val d'Aran sits in the Pyrenees, on the French side of the watershed but administratively in Spain, connected to the rest of Catalonia mainly through a single road corridor. On a good powder Saturday, or a summer weekend when the hiking and cycling routes are at their busiest, that geography turns into a bottleneck: every car funnels down the same road toward the same handful of ski resorts or trailheads, and the parking lots at the base fill up long before most people leave home. Without some way to manage that in advance, what you get is predictable — cars parked on the shoulder, blocked snowplows, and whoever's on duty that day improvising traffic control by hand.
That's the actual brief behind a parking-reservation web app we built around 2021, using that season's real numbers to size it. It's a Next.js app, and the interesting part isn't the framework, it's the constraints. You're not designing for steady, predictable traffic; you're designing for a demand curve that looks flat for months and then spikes hard on maybe a dozen days a year. The system has to make capacity legible before people leave the house: this lot has this many spots, this many are already claimed, reserve yours or plan on a shuttle instead.
- Demand isn't smooth — it concentrates in a handful of peak weekends a year, not steady daily traffic
- Capacity isn't fixed either — plowing, staff needs and emergency access all eat into the same lot day by day
- Most users aren't repeat users — a lot of people open the app once a season, from a cold car, with gloves on
I don't have the actual production logic in front of me anymore, but this is roughly the shape of the decision every availability check has to make — and that "never sell 100%" line is doing more work than it looks like.
def is_slot_available(lot, date, requested_spots):
capacity = lot.capacity_for(date) # capacity can vary: fewer usable spots on plowing/maintenance days
reserved = lot.reservations_for(date).sum(spots)
walk_in_buffer = lot.reserve_for_walk_ins(date) # never sell 100% of a lot online — leave room for staff and emergencies
return (capacity - reserved - walk_in_buffer) >= requested_spots
2. Waste doesn't wait for high season either
Parking gets the dramatic version of the seasonal-spike problem because it's visible. Waste has the same underlying problem with a lower profile. A valley whose permanent population is used to a certain rhythm of collection suddenly has to deal with a multiple of that volume once rental apartments fill up and every resort base area is running at capacity. That's the problem space JoRecicli sits in — a waste-management project we built for a client in the valley, listed on our site under "projects we've developed" rather than "our products," which tells you it was bespoke work for an institution, not something built to resell. The reasoning follows the same shape as parking: fixed collection schedules assume an average that peak season breaks, so the useful thing software can do is replace "because the calendar says so" with "because the container is actually full."
3. What civic tech actually looks like day to day
The parts of this work that don't make it into a case study are mostly about who you're building for. Public-sector and institutional clients move on a different clock than a startup does — procurement takes time, decisions go through more than one stakeholder, and requirements can shift for reasons that have nothing to do with the software. You don't get the "ship it and iterate next sprint" luxury either: a parking system for a ski valley gets almost all of its real usage on a handful of specific weekends, and if it falls over on one of them, there's no quiet way to patch it before the next test — the next test is next Saturday, in the snow, with everyone watching.
What makes it worth doing anyway is that the impact is unusually concrete. You're not chasing a growth metric on a dashboard; you're looking at whether fewer cars ended up parked on the shoulder this January than last. It's slower, less glamorous, and it will never get a product-hunt launch — but it's about as honest a test of whether something you built is actually useful as I've come across.
None of this is the kind of work that ends up in a "startups to watch" newsletter, and that's fine. What I keep wondering, though, is how much of what went into aparcaran and JoRecicli is actually specific to Val d'Aran versus how much of it would just work, with minor changes, for any of the dozens of other mountain valleys in Europe fighting the exact same battle every winter. We've never tried to find out. Maybe we should.