Building Muddy Boots

From a hiking group's WhatsApp thread to a working product the crew runs their trips on.

Anand Almal · 8 min read

Day two of the Lost Coast backpacking trip, there was no cell signal and nobody needed one. Seven of us were walking a 25-mile coastal trail with the tide tables in our pockets, and back home our families were watching seven dots move down the coast on a map. The dates had been voted on, the packs had been weighed against each other, the hotel split was already in. None of that existed before.

The short version: a twelve-person hiking group had no home for its plans or its history; they lived in WhatsApp, Strava, Google Photos, and two expense apps, and the next trip got decided on the trail by whoever was there. Over one summer I designed and built Muddy Boots, a private, group-first web app, with AI writing all the code. Ten weeks after launch, all twelve members were active and a three-day backpacking trip ran on it end to end. Next is finding out whether other groups like ours want it.

My role: product, design, brand, and the build direction; Claude Design and Claude Code as the tools, the crew as users and testers. June to September 2026, fifty-eight working days.

The bet: A twelve-person hiking group would get more out of a product built for the group than from four apps built for individuals, and I could build it alone in a summer if I built it with them.

Three weeks on strategy, sketches, and the design system, no code. First commit June 27, and the domain live the same day. Launch party July 16. Fifty-eight working days in all, around a three-week vacation, and ten weeks after launch the Lost Coast trip ran on it end to end.

1. Jun 4Scoping starts
2. Jun 27First commit, domain live
3. Jul 16Launch party
4. Sep 24–27Lost Coast, run end to end

Before Muddy Boots

Before the app, the next trip got planned in conversations on the trail, with whoever happened to be there that day. Ideas got tossed around and mostly forgotten by the drive home. "Which summit next? Who's in?" were the hardest questions the group had, and as the leader they were mine to answer: talking to a few core members one at a time, gauging interest and availability, and a lot of back-and-forth to land on dates that worked for most people. Once four people committed, I'd announce it on the WhatsApp group for everyone else to RSVP. The trips we'd already done had a different problem: twelve years of the group's history lived on individual accounts, Strava, Google Photos, Instagram, the chat. There was nowhere it belonged to all of us. And that place had to be private: ours the way the trail is ours on a Saturday morning, no audience, no feed.

I looked at what already existed before deciding to build. Strava clubs and AllTrails lists are individual products with a group feature attached, and both are public by default. Meetup is built for strangers finding each other, not twelve people who already know each other. A shared Google Photos album holds the pictures and nothing else; Splitwise holds the money and nothing else; WhatsApp holds the conversation and loses it. Each one does its job well, and none of them is a home: there was no product whose unit was the group, where the plan, the history, and the money lived together and belonged to all of us. That was the gap.

I had the summer. After twenty-five years leading design teams at Yahoo, Meta, and Google, I wanted to find out what changes when one person can run most of the product building loop with AI, and I wanted to do it for people I knew well.

The people

Twelve core members, mostly ex-coworkers from Yahoo, Walmart, and Google, held together by a few hours on a trail every other weekend. Finishing the Grand Canyon rim-to-rim changed the group; now the question is always what's the next thing we didn't think we could do. One of our most senior members climbed Mt Whitney at 56, three months after a cardiac intervention.

I built it for this group first, and designed it so any self-organized outdoor group could run on it: the data model is multi-tenant from the first commit, and nothing about our group is hard-coded. Muddy Boots the group is the proof; groups like it are the ambition. The order mattered: twelve people I knew would give me candid feedback fast.

Where to play

Three directions didn't make it, and each one taught me where the edges were. I started with a trail recommender, and it didn't survive contact with reality: AllTrails doesn't share its data with developers, and crowdsourcing trails from the crew didn't take off. So I moved toward what no one was doing for us: a private home for the group, where our plans, our history, and our wins live in one place. Group first, then member. And a line, drawn on June 9 before any code: no live tracking or navigation. Muddy Boots helps the group plan before and remember after; during an activity, Garmin, AllTrails, and Strava are already very good. The third was the open-ended assistant: I built Ask Muddy Boots expecting it to be the front door, and usage told me otherwise; more on that below.

Building in the open

The rule for what to build next was simple and I stuck to it: rank the group's jobs by how often we hit them and whether anyone can skip them, and build the ones nobody can skip first. Planning a trip and settling the money are unskippable; logging a hike is skippable if Strava already has it; chatting with an AI is skippable always. Cost came second, because with AI writing the code the expensive thing wasn't building a feature, it was building the wrong one and losing the group's attention. Validation was the crew: a launch party three weeks in, then every feature after that as a response to something someone did or said.

I shipped a thin shell on purpose: group stats, leaderboards, profiles, trophies, and a launch party three weeks after the first commit, so the crew would be using it while I found out what it needed to be. Every feature after that came from watching what people did and listening to what they said. The biggest hurdle was data entry: nobody would log an activity here when they'd already logged it on Strava. So I built a Strava integration, and what I hadn't expected was how much history came with it. Three days after launch, the full history import pulled every activity each member had ever recorded, in some cases more than a decade, and filled the log book in one pass. Then the photos came across, and the memories behind the stats arrived with them. Twelve years of data, and everything I'd built finally had something to stand on.

To bring people back I added a nightly trivia quiz mined from the group's own data, a dream hike of the day with a Sunday digest, and expenses that settle per trip, which replaced Splitwise and Tricount and became the stickiest thing in the product, because it's the one job nobody can skip.

What shipped

A private web app, phone and desktop. Five things carry it, and each answers something from the first section: trips with scheduling and RSVPs, for the "which summit next, who's in?" problem; an activity log book synced from Strava and photos by trip and by person, for the twelve years of history that lived on individual accounts; expenses, the one job nobody can skip; and two ways to talk to it, Ask Muddy Boots inside the app and an MCP server, built in three days in August, so members add trails, gear, and expenses from their own AI with no form to fill, which is how the data-entry hurdle got solved for everything Strava doesn't cover.

It runs on its own design system, a brand positioned alongside gear makers like Black Diamond rather than fitness apps: an instrument in the kit, not a feed. Twenty components and fifty-plus screen templates, made natively in Claude Design, not Figma.

Where AI holds real weight: the MCP server, which changed how content enters the product, and "Photos of you," which finds a member's photos in everyone else's rolls, so the interaction is "here are your photos," not "go tag yourself." The AI-written hiker profiles are decorative, and I'll say so.

Running it

Since the launch party on July 16 I've run it the way a small product team would. At twelve users, every fix is a conversation, not a dashboard, and the first thing the conversations told me was which AI people use. Trivia gets used by some members almost every day. Ask Muddy Boots, the open-ended chat, gets used least: the AI people use is the one that shows up with something specific.

The biggest thing that broke was the domain's reputation. I sent the URL to a few ex-colleagues at Google and it wouldn't load for them. The domain had been flagged as malware by one URL filter after another: Cisco Talos, Google Safe Browsing, Palo Alto, FortiGuard. I appealed to each, and some reclassified it. The likely cause: crawlers saw nothing but a sign-in page, and a private app with nothing public-facing looks, to a filter, like something hiding. So I built a public page that says what the app is.

Do people come back?

In September 2026 all twelve core members logged an activity, unprompted, and nine or ten of the twelve open the app in a typical week. The result I'd show instead of a quote is the Lost Coast trip: dates and attendees settled by RSVP in the app, planning in the Lounge, packs weighed against each other, $3,600 of expenses entered as they happened without a nudge, and seven of us over three days with the activities landing in the log book on their own. And our families followed us live on a page fed by the Garmin inReach devices we carried.

What's next

Everything above was validated with one group, mine; I haven't yet put it in front of a comparable group that doesn't know me, and that's the next test. Onboard a couple more groups to test the multi-tenant side of the product. The next step is getting the app through Strava's review, which is what opens the door to more members.

What I'd do differently

Start the import sooner. 96% of activities and 90% of photos in Muddy Boots got there through import. I built the features first and the engine second, and the engine was the one that mattered.

How I worked with AI

I gave the AI my vision, built the design system with it, iterated on every flow and screen, and handed the specs to Claude Code, which wrote all the code. I owned every decision about the product, the brand, the design system, and the experience. AI wrote every line of code. I wrote everything the code expresses, and I own what it does when real people use it.

What I took away

Don't compete with the incumbent's strength; build the thing it structurally can't. Contribution loses to consumption, so build the engine that collects on its own before the features that depend on it. Own one job nobody can skip. Where users can feel the difference, curated beats generated.

The bigger lesson was about leading design now. AI changed the cost structure of building, so I'd run design the way I ran this: design, build, iterate, with the iterating done in working code on real data, because for AI products a mock can't show you how the model behaves. The prototype becomes the spec. I've lived that at n of one, which is why I'd insist on it for the next team I lead.