NaturPark is one of the products we build at Maladeta Studio, alongside Lueira and MeteoTrail, and it sits at the intersection of two areas we care about: mobility in natural spaces and waste management. The tagline we settled on says it plainly — manage natural spaces in an innovative and secure way. But the interesting part of building NaturPark wasn't the tagline, it was realizing early on that "a natural space" is not one thing, and software that pretends otherwise breaks the moment it meets a second client.
1. One space, one rulebook — until it isn't
The first version of the idea in my head was simple: build a platform to manage natural spaces, ship it, iterate. It took about one real conversation with a park manager to see the problem. A coastal wetland cares about tidal access windows, nesting season restrictions, and boat traffic. An alpine reserve cares about trail conditions, avalanche risk, and seasonal closures that have nothing to do with tides or nests. Both need visitor management. Neither needs the other's rules.
That's a common trap in vertical software: you build for the first client, generalize a bit for the second, and by the third you're maintaining a pile of conditionals and hidden feature flags that nobody fully understands anymore. We didn't want to get there by accident, so we tried to decide on purpose, from the start, how far the platform would flex — and where it would draw a hard line and say "this is core, everyone gets it."
2. Designing for modularity
Not all spaces are alike and each has its own needs — that's the whole premise, and it's why we designed the platform to be modular and scalable rather than a fixed bundle of features. In practice that meant separating a small core (space profile, staff accounts, base visitor data) from a set of independent modules that can be switched on or off per space: things like visitor counting, incident reporting, trail status updates, or waste collection routes, depending on what a given space actually operates.
The illustrative modules above aren't an exhaustive list of what shipped — they're the kind of thing the architecture was built to support, given the mobility and waste-management work we do. What mattered more than any single module was the mechanism: a space's configuration decides what its dashboard shows, what its mobile app asks field staff to log, and what data model gets provisioned underneath.
{
"space_id": "aiguestortes-01",
"name": "Aigüestortes",
"modules": {
"visitor_counting": true,
"incident_reporting": true,
"trail_status": true,
"waste_collection_routes": false,
"boat_traffic_control": false
}
}
The admin panel is where this configuration actually gets edited — someone onboarding a new space picks the modules it needs, and everything downstream, from the manager's dashboard to the checklist a ranger sees on their phone, adapts to that choice instead of showing dead menu items nobody asked for.
3. What the three faces of the product look like
NaturPark isn't one interface, it's three, each built for a different kind of user and a different context of use. The web dashboard is where a space's management team gets an overview. The admin panel is where modules and settings get configured for a given space, usually by whoever is onboarding it or by us during setup. And then there's the field app.
The field app is the one that has to work with none of the comfort a desk job gives you: intermittent connectivity, gloves, sun glare on the screen, someone who wants to log an incident and get back to walking a trail, not fill out a form. Designing it meant constantly pushing complexity back toward the dashboard and the admin panel, and keeping the field surface as close to "tap two things and move on" as the modules enabled for that space would allow.
4. What we'd do differently
Modularity is easy to sell in a pitch and harder to live with in code. Toggling a module per space sounds like a checkbox, but it touches permissions, data modeling, and testing. We leaned on the assumption that modules are independent more than I'd like to admit in the early build, and it mostly held — but "mostly" is doing some work in that sentence.
If I were starting NaturPark today, I'd want the module boundaries defined with the same rigor we gave the tagline, from day one, instead of discovering the honest boundaries a client conversation at a time. NaturPark still runs on that same core idea — different spaces, different needs, one platform underneath. What I'm less sure about, years later, is whether "a module per feature" was the right granularity, or whether the real unit of variation was something coarser that we split into modules mostly because it was easier to build one at a time.