When I booked my 2025 hut-to-hut hike in the Austrian Alps, I looked at the daily distances, then at the elevation gain, and my honest first reaction was: oh dear God.
Here's the problem. I used to be a park ranger. Staying fit wasn't a goal I had, it was just what the job did to you. Then I became a software engineer, and now the job mostly does the opposite. These days, every time I want to do a big hike, I have to actually train for it. This is new information for my body and it is not thrilled.
And I don't like the gym membership fees. What I love is walking out my front door and finding out what's in my own neighborhood. That feeling of discovery is a big part of why being a ranger suited me, and most of why I want to see more of the world. But I didn't have a car, so Washington's trails, gorgeous as they are, were mostly out of reach on a weekly training schedule. So I trained the only way available to me: I wandered around my neighborhood and guessed. Was it enough distance? Enough hills? Should I be doing stairs? How many? Carrying what?
What I wanted was an app that would just tell me. This week, do this trail. Can't get to a trail? Fine: walk these four miles and do the water tower stairs six times. A plan that ramps you up a little each week, starting on your own sidewalk and ending at the summit you signed up for. (If you're already guessing where the app's name came from: yes, exactly.)
The eight months I didn't build it
I even had time to build it. I'd been laid off that February and didn't start my current job until October. Eight months. I called it my founder year, with some generous rounding.
I tried. First as a native Android app, where the maps ate me alive. Everything map shaped was either expensive or missing the API I needed, and I stalled out. So I pivoted to a circular economy app idea, partly because King County had grants and incubators for that kind of work. I spent months on business model canvases and persona research. At some point I caught myself writing a business model canvas and personas for the hiking app on the side, like a kid doing their real homework under the desk.
Then the eight months were up. I had a stack of research, a new job, and exactly zero shipped software.
I did the hike, by the way. It kicked my butt, even with the training I'd guessed my way through. Somewhere on the second day of switchbacks I remember thinking: I wish that app existed.
The lesson I actually took from those eight months: if you ask people whether they'd like your app, they say yes. That's not a signal, that's politeness. The only honest test is putting a real thing in front of real people and watching what they do. So this time, "send it to real hikers" isn't a hope. It's a numbered task in my build plan (T33), and it has a gate: it can't fire until the things first users actually need are live.
What I'm building
Sidewalk to Summit. You pick a goal hike, real or dream (yes, you can type in Kilimanjaro), tell it a little about yourself, and it builds a week by week ramp out of what's actually around you. Real trails when you can get to one. Urban hikes, neighborhood walks, and stair sessions when you can't.
And it'll find the stairs for you. This was my favorite discovery of the whole planning phase: Seattle publishes its maintained public stairways as open data. I was about to price out paying strangers to walk around counting steps, and it turns out the city already counted them. If you have a treadmill, you can tell the app that too. That's about the only thing it can't find for you.
The first real architecture decision happened before any app code existed: the math and the words are kept strictly apart. A deterministic engine computes every number in your plan, because a training plan that overprescribes can injure someone. An LLM writes the friendly explanation around those numbers, and it is never allowed to invent one. Building evals and guardrails for AI products is what I do in my day job, and this is the same discipline pointed at my own app: every numeral the LLM writes will have to trace back to the engine's output, and that rule will be enforced in CI, not in a code review comment. There's a whole post coming about this once it's built and defended by tests.
(Why "Sidewalk to Summit" and not the couch-themed name it started with? That's a story of its own. Coming soon.)
How I'm building it
One small task a day, 15 to 45 minutes (though some days I'm hooked on the vibe coding and run long). I plan, an agent writes the code, I verify. Plan, code, verify, repeat. (It's a cousin of the daily self-evals habit I wrote about here.) The planning lives in a knowledge base repo that is the source of truth: the specs, a decision log, the backlogs, and this devlog. The rule is one task per working day. Miss a day? Do that task the next working day. And the devlog is where I admit when I don't hold to it.
The method has to survive real life, because before this build is done it will cross an ocean with me. That's on purpose.
Why like this
My company is called The Pond's Edge, and the name is the whole thesis. Life thrives at edges. The pond's edge is where things grow and change and expand. Park ranger to software engineer was one edge. The edge I'm walking now is designing work around a life instead of the other way around: flexible hours, four-day weeks, living in other countries for months at a time. It's a constraint I'm engineering within, the same way the app has to work for someone with no car and no gym.
If this app succeeds, the win isn't downloads or revenue. It's proof that the working style works. That one small task a day, planned carefully and verified honestly, is a real way to build software and live on your own terms.
Follow along here: dated entries in the running devlog, standalone posts when something real ships.
Top comments (0)