My Journey Designing an Invisible Safety Canopy: The Story of pTreks
Every great outdoor adventure begins with a single step, a clear trail map, and a spark of inspiration. For me, the spark that would eventually become pTreks was struck back in 2020 - but the fuel for that fire had been quietly gathering for over a decade.
If you have ever organized a group outing in the wild, you already know the weight that sits on your shoulders before anyone laces a boot or turns a key. You are juggling the itinerary, chasing RSVPs, collecting emergency contacts, running headcounts at the trailhead, and praying nobody gets separated in dust, switchbacks, or dense timber. Once the trip is underway, the anxiety shifts: Who fell behind? Who took the wrong fork? Who has been quiet too long? I kept asking myself the same question: How do we use technology to lift that burden without stealing the freedom that makes these trips worth taking?
In this post, I want to share the personal story of how pTreks came to be - not a product brochure, but the path I actually walked. It runs through early experiments with motion-sensing phones, a shelved prototype called Riding Radar, a part-time detour modernizing a historic motorcycle club’s website, and ultimately a ground-up rebuild of the apps so groups could carry an invisible safety canopy into the backcountry.
Where the obsession started (2010–2012)
My fixation on field safety and group navigation really began in 2010. I have always been fascinated by how moving groups coordinate - biologically and socially - and I had spent years building software. When Apple opened the early iPhone SDK, I was less interested in screen rotation than in the accelerometer sitting in everyone’s pocket. I started sketching Riding Radar: software that could recognize a hard deceleration or impact signature and automatically ping the people around you.
By 2012 the idea had grown into something richer. I wanted a peer network where travelers in trouble could find nearby companions with the right gear and goodwill - a cyclist with a flat matched to someone carrying a tube, a rider with a puncture matched to someone with a pump. At the same time, the phone would watch for crashes and falls so the group was not relying on someone remembering to call for help.
Then reality intervened - not in one dramatic way, but as a stack of 2010-era constraints that would take years for the industry to outgrow. Always-on GPS could drain a phone in a couple of hours when you needed it most; that was real, but it sat alongside tight memory and storage (16 GB felt generous), immature mobile frameworks and tooling compared with what we have now, and background location APIs that were nowhere near today’s deferred updates, geofencing, and power-aware modes. Cloud backends existed, but the patterns we take for granted - reliable real-time sync, cheap always-on servers, polished DevOps - were still being invented; most serious teams rolled their own on bare metal or early VPSs, as we still do on ours, but with far less ecosystem support around them. I spent months on paper designs anyway - coarse grids for fast movers, tighter grids for hikers, trading naive polling for good enough, soon enough location - and partnered with an iOS developer on a prototype. What finally shelved Riding Radar was simpler and more human: software was never my day job. Executive demands at the medical startups I was running left little room to push a side project across the finish line. The app never shipped - but the ideas (efficient geolocation, peer assistance, sensor-triggered alerts) never left me, and when I picked the work up again in 2020, modern phones and native SDKs finally made the hard parts tractable.
Why I picked the project back up in 2020
Fast forward to the pandemic. I was semi-retired, suddenly with time at home, and I heard that old question again. Group coordination had only gotten more fragmented: RSVPs in email threads, routes in one app, chatter in texts, safety check-ins when signal allowed. When someone dropped off the back of a ride or hike, it could take minutes - or hours - to notice and even longer to guess where they were.
I went back to the drawing board and built a proof of concept with Node.js, MongoDB, and React Native. It was the right stack to learn quickly and prove that live position sharing could work. Field testing taught me the harder lesson: a generic cross-platform shell was not going to give me dependable background GPS, tight geofencing, or trustworthy access to motion sensors on the devices people actually strap to handlebars and sternums. The vision was right; the foundation needed to mature.
What years on the road added (2022–2025)
In 2022 I noticed the BMW Owners Club of San Diego (BMWOCSD) - founded in 1970, full of motorcycle riders who had crossed continents - was living with a website that no longer matched how the club actually rode. As a charitable side project in semi-retirement, I rebuilt their site bit by bit: member data, payments, calendars, ride briefings. It was never a full-time job, and I would not call it a turning point in itself. What it did do was keep me in the orbit of that club for years - riding, listening, and watching how a pack actually behaves when the miles pile up.
By then I already had a personal ledger of group outings: road cycling, ski tours, family hikes in Utah and California. Motorcycling added something different - tens of thousands of miles on the road beside people who had made a life of it. Veterans who could read a corner, a pace line, and a tired rider at the back without drama. That is where most of my aha moments landed: not from rebuilding a website, but from being in the pack long enough to see what works, what fails, and how fragile the whole chain can be when one link forgets their job.
The website work taught its own lessons on the technical side - how to run member email, calendars, ride briefings, and the back-and-forth that keeps a club functioning. Several concepts I tried there carried forward into pTreks when the time was right: Moments (geo-encoded photos and videos with metadata linked to the group, the trek, and the participants who shared them), emergency contacts kept current in software and instantly available to trek leaders as ICE (In Case of Emergency) data, trek resources (maps, waypoint information, leader notes, and the briefing material people actually need at the trailhead), and automatic notifications so event planning did not hinge on one volunteer remembering to send another round of email. I saw clearly what electronic tools can do well and where they become noise. These riders had been crossing continents for decades before mobile phones or club websites added anything meaningful to the sport. Whatever software I built had to fit a purpose and stay out of the way when it did not - not lecture people who already knew how to look after each other. Technology can still help, I believe that firmly, but only when it earns trust: scoped to a real job, respectful of how the group already works, and optional enough that nobody feels the trail has been replaced by a screen.
They taught me three human protocols that had kept groups alive long before smartphones:
- The ride leader - plans the route, sets pace, leads from the front.
- Posting corners - each rider is responsible only for the person behind them. Lose them at a fork, you stop and become a visible signpost until they are accounted for, then you move on before they commit to the turn. One missed post and someone drifts wrong; the whole chain depends on discipline, not heroics at the front.
- The sweep - the last rider, watching the tail, collecting anyone who mechanicals out, misses a turn, or needs help.
The leader cannot see the back of a large pack. Safety is a human network. I watched it work beautifully on long days in the saddle - and I watched it fail when one tired rider forgot to post. That fragility stuck with me.
Those dynamics are not motorcycle-specific, but the road gave me the clearest, longest look at them. Backpackers, cyclists, ski tours, family hiking groups - they all share the same blind spots. I started imagining software as a digital ride leader, corner poster, and sweep: everyone on one map, automatic signals when someone stops or falls behind, without replacing the autonomy people cherish on the trail.
How I modeled it in software: Groups and Treks
Translating club culture into code forced me to separate community from the live event:
- A Group is your permanent home base - the club, the friend circle, the family unit. Rosters, planning, history, conversation between trips.
- A Trek is the live adventure: the scheduled outing where maps, messages, and location sharing turn on for the people who opt in.
I still explain it to people this way: you live in the Group; you execute safety in the Trek.
What I want you to feel in the field
When a Trek is active, pTreks is meant to stay out of your way and show up when it matters:
- See the whole team on a shared map - not guesswork about who is still on route.
- Get alerted when someone stops moving, falls behind, or goes quiet so the group can respond with a coordinate, not a vague “where are you?”
- Talk inside the Trek instead of scattering updates across texts that half the group never sees.
- Reach ICE (In Case of Emergency) contact details in context when seconds count.
That is the practical side of the canopy. The philosophy side is simpler - and it depends on knowing what pTreks is not trying to be.
Drawing a clear product line
Translating BMWOCSD’s world into software also surfaced a boundary I had to respect. On the club website I was building the unglamorous but necessary machinery: bylaws, sponsorship tracking, membership dues, financial bookkeeping, and the formal legal structures that hold a decades-old organization together. The more time I spent in that work, the clearer it became that those features did not belong in pTreks.
A real-world club is a standalone legal entity with governance and books that matter on their own terms. In pTreks, a Group is deliberately different - lightweight, democratic, and focused on the outdoor adventure itself. A pTreks Group is not a legal corporation or a tax-exempt entity; it is a functional gathering of explorers who want to plan trips, stay in touch, and look out for one another in the field.
So I made a deliberate product decision: leave bylaws, dues, and ledger-style admin on the club site (and in the tools clubs already trust), and keep pTreks aimed at peer coordination, shared trails, and trail safety. That is how we protect a fast, clean experience that stays honest about what actually happens once you leave the pavement.
Why I chose a hard rebuild for production (2025)
By 2025 I was done pretending the first stack could carry real backcountry use. The 2020 proof of concept taught me the vision was sound; field testing taught me the foundation was not. Cross-platform shells looked fine in the lab and fell apart on a mountain pass - background GPS that slept when the phone locked, geofences that arrived late, motion cues that never fired reliably. If pTreks was going to be a safety net people trusted with their friends, it had to be native and boringly reliable - the kind of software that earns its place in a jacket pocket and never asks you to babysit it.
So I rebuilt the mobile clients in Swift (SwiftUI) for iOS and Kotlin for Android, using Apple and Google’s location, geofencing, and sensor APIs the way they were meant to be used - not through a compromise layer. Persistent and spatial data moved to PostgreSQL for integrity and fast coordinate work. The real-time layer stayed on Node.js with Express and WebSockets for live positions and in-trek messaging. For planning, organizing, and watching from home, I shipped a React web dashboard - including View-Only participation so family, coordinators, or anyone who is not on the trail can follow an active Trek without needing a handlebar mount.
That engineering stack matters, but what I care about is what it unlocked for the people I built this for.
When you activate a Trek, the invisible safety canopy turns on - only for the participants who opted in, only for that outing. Everyone who joined sees the whole team on a shared map, not a guess about who is still on route. If someone stops moving, falls behind, or goes quiet, the group gets a signal with a coordinate, not a vague where are you? text buried in a thread half the club never reads. Trek-scoped messaging keeps updates where they belong; ICE (In Case of Emergency) contacts sit one tap away for trek leaders when seconds count; trek resources - maps, waypoints, leader notes, briefing material - live in the same place as the live event instead of scattered across email attachments.
Moments carry the human side forward: geo-encoded photos and videos tied to the group, the trek, and the people who were there - a shared scrapbook that remembers where the day happened, not just that it happened. Automatic notifications for planning and schedule changes spare the volunteer organizer from sending one more round of did everyone see this? email. And when you are back at the keyboard, the web app is where groups take shape, treks get scheduled, and the story of past outings stays organized - while the phone in your pocket does the quiet work of staying connected in the field.
This is the digital ride leader, corner poster, and sweep I imagined years earlier on paper - finally implemented with hardware and software mature enough to respect how adventurers actually behave. pTreks does not replace the human protocols that kept packs safe for decades; it backs them up when someone forgets to post, when dust hides the rider behind you, or when the sweep is still three switchbacks back.
It was months of unglamorous engineering. I am proud of that phase precisely because nobody will see it. They will only notice when the map updates with a phone locked in a pocket, when a coordinator at home exhales because the whole line is moving again, and when a group realizes they spent the day looking at the horizon instead of their screens - but still had each other’s backs.
Where we are today
pTreks is no longer the 2020 sketch on my desk. It is a working ecosystem for people who want “Going places by yourself… surrounded by friends.”
I built it for explorers who value solitude on the ridge and still want the group to have their back. The app is designed to run quietly - sync in the background, speak up when someone needs help, and never compete with the reason you went outside in the first place.
We are in active alpha and beta on iOS and Android. If you ride, hike, or lead groups and you are willing to break things kindly in the field, I would love your eyes on it.
Thank you to everyone who cheered from the sidelines since the Riding Radar days. I’ll see you on the trail.
If you want the deeper dive
This post is the story. Our official platform introduction and technical history on the pTreks newsletter goes further: full timeline, architecture notes, screenshot tour, feature video, and the editorial roadmap for upcoming deep-dives (native apps, web dashboard, view-only mode, and more). Read that when you want the reference manual; read this when you want the why.
Stay tuned for more. In the coming weeks I will keep writing about our journey to make pTreks a strong platform for real-world group coordination and collaborative exploration - not a destination you visit to kill time, but a tool you open when your people are actually heading outdoors.
To be direct: we are not building another social media platform designed to capture your attention or keep you glued to a screen. My focus is utility - helping genuine, face-to-face gatherings run smoothly and safely. I want pTreks to feel seamless for active clubs, hiking circles, and groups of friends who already plan to meet in the real world and only need a quiet layer of awareness while they are out there.
You will see more of that story here on the blog; deeper technical and product pieces will live in the newsletter. I hope both help you decide whether this is the kind of companion your group has been improvising without.
Ready to help shape what ships? Join the pTreks Tester Program for early access on iOS and Android - or visit ptreks.com to learn more about the platform, the newsletter, and how to get involved.