Building Software for Belonging
How we built Tierra Libre Run, a BIPOC-created, BIPOC-led nonprofit platform that uses modern software to provide financial access, community, and belonging for runners of color in trail running.
The core challenge in outdoor access is that it's not accidental. Endurance sports are filled with invisible prerequisites—from gear knowledge to safety confidence. Simply providing a discount code doesn't solve this; access is an ecosystem, not a transaction.
As a software engineer, I sought to answer: How do you build software that is relational, intentional, and designed to support true belonging?
This became the blueprint for Tierra Libre Run, an approach applicable to any community-centered outdoor space.
Principle 1: Access is a Guided Workflow
Access is the whole journey, not a single feature like a free race entry. Designing for belonging means creating a platform that functions less like a transactional "benefits portal" and more like a guided, relational workflow.
This workflow recognizes where the athlete is and provides support appropriate for that stage. We structured the platform around three core, interconnected modules that must work together: a Funding Module for financial support, a Mentorship Module for guidance, and a Community Events Module for sustained, local engagement.
The product’s value is in the connection between these parts.
Principle 2: Relationship Data Is Primary
Our core architectural decision was to treat the participant not as an "athlete" with attributes, but as a "narrative." The application forms are designed to collect stories—the athlete’s journey, their barriers, and their specific needs.
This is more than optics; it’s architecture. By treating people as stories, the platform becomes a site of recognition rather than a tool for data extraction. While we use structured data for analytics, the system is designed to intentionally slow down to protect and prioritize the human meaning in the narrative.
Principle 3: Optimize for Maintainability
An access ecosystem scales like a forest, not like a server. It requires tending to relationships and creating the right conditions, which is why optimizing for infinite, viral scale is a trap.
Our technical stack (Next.js, PlanetScale, TypeScript) prioritizes legibility and modularity. This focus on maintainability ensures that the platform can evolve as the community does, and eventually, it could be a system the community itself is equipped to sustain.
Principle 4: Transparency by Design
Outdoor access work requires shared accountability among all partners—organizers, brands, volunteers, and athletes. If the system cannot clearly explain where support goes, trust breaks down.
Therefore, reporting is part of the product, not an afterthought. We built internal views and dashboards that automatically track funding outcomes, summarize reach, and map mentorship networks. When partners and athletes have this transparency, they invest more deeply and feel part of a larger, shared mission.
Principle 5: Design for Circulation, Not Just Entry
Once a participant runs their first race, their identity changes. They are a "trail runner." The platform’s job is not just to support entry, but to support circulation—the journey from participant to leader.
The system is designed to support the full circle: moving people from receiving funding and mentorship to racing, mentoring others, and eventually leading community building efforts. This is how access becomes genuine transformation.
Software as Cultural Infrastructure
This blueprint is about designing around the journey into belonging. It forces us to name the hidden prerequisites, protect the slow and personal moments, and enable participants to return as leaders.
We are building tools not simply to get people outside, but to fundamentally reshape who the outdoors is for.