Tag: hiking

Taking Dad along, the only way I can

One of the things I’m extremely skilled at is thinking of a brilliant idea while doing something else more important. That’s how I came up with TA Dispatch, a live website I can publish my daily rambles on while walking Te Araroa, New Zealand’s long pathway that extends across 3000 kilometres, from the top of the North Island all the way to the bottom of the South Island.

I was already building a daily journaling app that’ll structure my entries, date and location tag them, and identify emotional themes in those entries. The plan is to someday write a series of articles or even a book about this trip. These structured notes would be good fodder.

But good fodder for me could also be comfort to Dad, who has no social media and so no way of following my trip. Of course, I’ll call and text him as often as I can, but I still wanted something he could bookmark, open every morning, and be reassured that I’m OK.

Dad is of a certain generation that never saw or heard of men speaking openly about their feelings, challenges, and insecurities. Since my mum died a couple of years ago, he’s spent a lot of time on his own, contemplating. He was still working through some of that shit when he got his own health scare, which landed him in hospital for an open heart surgery.

It really wasn’t the best time to tell him I’d be off into the wilderness for months on end. As if that wasn’t hard enough, I also had to watch him try and process the enormousness of the trail, of water crossings, and alpine tracks.

I mean, I was processing the scale of the trail, and I’d been wanting to do it for over 7 years. The man had just heard about it!

And so, TA Dispatch was born.

But it didn’t come out all perfect and blemish free. Until this point, everything was only about my personal preferences and habits. And that was hard enough. To create something for someone else, while also staying true to the essence of the project wasn’t straightforward at all.

The good thing is that I have a fairly good idea of what Dad would want. He’d want to see where I am. He’d want to see the surroundings, how big my pack is, what I’m eating, how much I’m walking every day, whether I’m injured at any point, and how I’m feeling.

There’s no way Claude and I could build something that’d encompass all of those, in the time we had. WhatsApp does a reasonably good job of covering most of those requirements. I already call him on it daily and send photos and videos. No use trying to wean him off WhatsApp and onto a different platform just because I built it. At the same time, I wanted something outside of WhatsApp, one I can use as a broadcast medium without having to add too many battery-consuming actions.

I decided on a simple webpage that’ll automatically publish entries from my notetaker/journal app. I’d already built most of it, so the infrastructure was there. All I had to do was choose a bunch of these entries and publish them to a different page. Then came the layout and content. I thought a progress bar would be cool—so Dad could see how far I’ve gone and how much further I still have to go. Then the idea evolved and I wanted to incorporate a progress bar on the New Zealand map. The idea was to have a lighter line marking the full trail, and a darker line over the distance I’ve covered.

Oh, but what if I don’t have internet connection over a long stretch?

The progress would stop progressing and Dad would panic as dads do. Intellectually, he’d know I’m probably off grid for a while, but that won’t stop him from conjuring scary scenarios in his head. So Claude and I decided to add a little section that addressed the elephant in the room. We titled it: “What no news means.” It was basically a block of text to tell Dad that if the progress bar stopped, it’s probably because I’m out of coverage area (which is rather common on the trail) and not because something had happened.

I told Claude to go off and make those changes. When it came back, I realised my theory didn’t translate well practically.

Claude wasn’t great at drawing maps. It wasn’t terrible; you could still tell it was the map of New Zealand, but it was more like a blob than a living, complex landmass that’s constantly shifting, growing, and shrinking.

I decided to scrap the map altogether. Seemed easier than re-prompting Claude to fix the map exactly as I wanted it.

Instead, I included the kilometre marker, captured from my phone’s GPS, and the name of the section for each entry. That way, he’d still know I’m making progress without a stalled map tormenting him. I also got rid of the “What no news means” section for good measure. A kilometre marker would always be “current” because it only publishes when I want to, and is within my control, but those kilometre markers aren’t accurate. They’re just a close estimate, enough for Dad to know which general area I’m in without my exact location.

The purpose was to build something that didn’t already exist in one form or another. For instance, I’ll be carrying a personal locator beacon, a safety device that can pinpoint my coordinates to the emergency services, in case disaster strikes and I need to be airlifted. So I didn’t want the page to be my locator. I factored in rest days and admin days in my broader trail estimate so that the page doesn’t have to countdown the days to my return. In other words, I wanted something that’d fill in the gaps without causing too much anxiety for Dad.

He’s a worrier and nothing I could say or do in these last few days leading up to the trip is going to convince him it’s all OK. Still, I couldn’t leave without giving him something to follow along.

In just a few days, I’ll know whether all the work, time, and energy I put into this thing is worth its salt. One way to find out.

—

This is post 5 of 5 of me using Claude Code to build an app for my Te Araroa hike.

Post 1: The notebook guy started it

Post 2: Who will I be on trail?

Post 3: Kill your darlings, they keep saying

Post 4a: Yes-or-no questions are a bit limiting, apparently

Post 4: Not sure I can call it an agent anymore

Yes-or-no questions are a bit limiting, apparently

“Wouldn’t it be better to publish directly to your blog, though?” My engineer-brother, who can’t help but make everything around him more efficient, asked me.

I was telling him about my Claude Code project, the note taking system I’m building to help me document my days on Te Araroa, the long tramping trail that goes through the entire length of New Zealand. We’re both starting to walk the trail next week, so we were talking about it and around it, as you do.

You see, I’d built a web page (with Claude Code), where my notetaker app would directly publish any of the entries I chose. I call it TA Dispatch.

If I were to publish my trail notes directly to my blog instead of TA Dispatch, I could drive traffic and attention to my blog, a platform I’ve been writing on for 15 years.

Yo, bro. I know you’re reading this. Here’s your answer.

I had considered plugging my blog into my notetaker app. It’s the first thing I thought of when I decided it’d be nice to have something my dad and friends can use to follow my walk. Then I looked at the practicalities of it.

It wasn’t rocket science. I had to use WordPress’ write API so that every time I selected an entry on my notetaker app, it’d “write” and publish that as a post on my blog. I knew I could make it work. But Claude said something that dissuaded me.

It said I’d need internet connection for the API call to write and auto-publish. If anything were to fail in that process because I was out of network range, that entry might not publish on the blog at all. And I wouldn’t even know.

That made sense, I thought. I didn’t want another potential point of failure—I already had a system to back up my entries, and that could fail too. One risk was enough for me.

But my brother, as most siblings do, has a way of getting in my head. After his comment, I went back to Claude, and asked it to remind me why I’d decided against it. It told me the history. But this time, it also said something else:

If I really wanted to, I could still use the API. In fact, it wouldn’t be any more risky than the setup I had for backing up my entries.

Then it gave me options. Like adding the TA Dispatch page to my blog’s domain. My notetaker would still only publish to TA Dispatch, but the page would “live” on my blog.

I wanted to kick myself for not thinking of that.

Then I wanted to kick Claude for not suggesting it the first time.

As I was writing this, I asked Claude to review it. That’s when it pointed out something I hadn’t realised before: it didn’t give me options before because I didn’t ask for options.

When I first considered using the WordPress API, I’d asked Claude to do or not to do the API. Claude suggested against it.

When I went back after my brother’s observation, however, I reframed the question. Now it wasn’t a yes-or-no, but a why question. The scope was broader and my objective clearer. Claude responded in kind. It explained my initial decision and offered alternatives.

That was a fascinating experience. You hear so much about good prompts and bad prompts. There are even AI tools that convert mediocre prompts into robust ones. But I never expected a casual question, mid-conversation, would need to be as rigorously structured—because that’s not what we do when we talk to people.

If I had had the same conversation with a WordPress expert, they’d have asked me follow-up questions about what I wanted to achieve. Or they might already know the context if we’d been going back and forth on this project like I’d done with Claude. They would’ve offered suggestions earlier on and I might have considered the API option more seriously.

In the end, I didn’t use the API. But as much as I hate to admit it, my brother had a point. So I moved TA Dispatch to my blog.

Check it out: https://te-araroa.narmadhaa.com.

—

This is post 4a of 5. Because I wrote this while putting off writing the actual post 4.

Kill your darlings, they keep saying

For a few months now, I’ve been working with Claude Code on an experimental project. It’s a system to help me document my days and emotions while I attempt to walk the entire length of New Zealand.

Most people who walk this trail document their journey on social media. Instagram is naturally the best fit, because it’s audiovisual and doesn’t penalise you too much if you don’t post chronically. TikTok is another popular choice. For those who use these two platforms to post shorter videos throughout their journey, YouTube is the endgame. Open it up and you’ll see day by day logs, hour-long documentaries, and detailed series that capture the essence of what it’s like to be on this epic adventure.

I wanted to post on Instagram as well. But I also wanted to document daily notes just for myself. As notes. That I can look back on. Like a journal, in written form.

So I planned it. I knew I might be too tired after walking 8-9 hours to sit down and type into a phone. Even though I’ve written several long-form pieces on my phone before, part of me doubted that I’d do that on trail.

It was easy enough to build the shell. The interface was decent with an option to record voice notes, that would be transcribed and cleaned up before saving. And because I like to double check my work and double bag my electronics, I also decided to have a text-only log. That way, I could write or talk into my phone, depending on my mood.

I tested it. Neither the record button nor the save text button worked. I sat down to diagnose. After a lot of back and forth and enabling and disabling the developer menu on Safari, I learnt how to verify the error. A bit more back and forth with Claude Chat and we finally fixed the save text button. By then, it was 2am and we still needed to figure out what was wrong with the audio record button.

So I fell asleep and forgot about the project for two weeks. That was my reality throughout this process—I didn’t magically build a fabulous thing over a weekend. It took me months. Work and life happened. No matter how much I wanted to ignore the world and play with Claude, I had other commitments to honour, a father recovering from surgery, and a family that loves to be dramatic.

When I eventually returned to Claude, we went through several attempts to fix the issue before realising I needed to sign up to a voice transcription service, connect its API to Claude, and only then would my record button work.

Obviously, that’s common sense. However, I was under the impression that Claude Chat, with all its mightiness, could transcribe audio. In the planning stage, I didn’t ask the question specifically so Claude didn’t tell me.

Now I know Claude can’t transcribe audio. Neither can ChatGPT. But Perplexity does a pretty good job—it even transcribed Tamil, my first language.

Then I had to contend with two options: Sign up to a transcription tool and connect that to my Claude app. Or ditch the voice recording feature entirely.

The purpose of this project was to be able to talk into my phone. I didn’t want to get rid of it.

I took several days to think it over and kept coming back to the same idea: What if the transcription connection failed mid-way?

I’ve worked in tech long enough to know that every piece of tech you plug into another piece of tech—like adding more weight to your bicycle rack—is a potential point of failure. This is how software works. When something’s off, you check the plumbing, where things connect with each other, because that’s almost always the cause for a leak.

I went down that thought process rabbit hole. If transcription does fail for whatever reason, I would know fairly quickly. But there’d be no way to fix it while I’m on a 3000-km tramp. I mean, strictly speaking I could, but it’d be tedious and not what I’d want to do on trail anyway.

Then there’s the issue of backup. I wanted all my entries (text and voice) to be backed up to my Zoho WorkDrive account. In case I dropped my phone in the Whanganui river, everything I’d done until that point would still be safe. If transcription fails and I fix it, then I’d also have to re-check the backup status. All of this is super simple when I have a laptop connected to a stable internet connection, sat in my home with a hot coffee by my side. It’s torture to work all of that out on my iPhone, with spotty internet, in the backcountry, sitting on an uncomfortable rock, hungry and sore from walking all day.

If transcription fails and I don’t fix it, I won’t have an alternative voice recording system that’s as efficient and battery-conscious as the one I was trying to build. My phone’s voice notes would be fine, but they’d become messy. They won’t be automatically location-tagged or categorised by emotions and regions—a feature I definitely wanted.

Eventually, I decided to remove the voice option altogether. Going the extra mile to build it didn’t guarantee reliability. The extra work and admin didn’t justify the risk.

This was my biggest disappointment in the whole process: Having to kill the thing that got me started.

Even without the voice recording feature, I still have other potential points of failure in my app. I’ve done what I can to minimise niggly issues, but the real test would be on trail. One way to find out.


—
This is post 3 of 5.

Who will I be on trail?

A little while ago, I decided to create something with Claude Code to help me document my upcoming hike along Te Araroa—or TA. It’s a 3000 kilometre walk from one end of New Zealand to the other. I’m going southbound—so from Cape Reinga at the top to Bluff at the bottom of the South Island.

Map of Aotearoa New Zealand with the Te Araroa trail running through it
Source: https://www.teararoa.org.nz/map/

I’ve never done a multi-day hike before. I’ve done lots of day hikes of varying complexities but I’ve never had to worry about not having phone signal for long stretches or being out in the wild having to fend for myself. So I don’t know what that would do to me physically and psychologically. Which is fine, and is kind of the whole point of doing the hike—to challenge myself in ways I never have before and to hopefully find the courage and resilience within me to keep going.

I don’t know the person I’d become on trail, so building any piece of technology for this person is a bit tricky. I mean, would I want to sit down and write long drawn essays at camp after walking 25 kilometres a day? What would my tolerance be like after 20 river crossings and a big gash on my foot, surrounded by sandflies? Would I even care about writing the story then as I care about it now? Maybe, but also maybe not.

And that’s a problem. Because good technology understands the user’s mindset and behaviours. For instance, if you’re sat in an office with access to unwavering internet, you take it for granted that Safari will load your website without glitches. But when you’re going in and out of network areas all day, would you prioritise sending a message to your now-single and post-heart-surgery dad or would you try and open a website?

So many questions and so few answers. That’s what I was dealing with when I first went back and forth with Claude to see what we could build together.

As nerve wracking as that was, it was also one of the best lessons from this process: I had to do my best without assuming anything about my future self.

So I started making a list of things I need to factor in, while still allowing room for failure.

My solution needed to be as light weight as possible. It needed a daily journal log, and tags and categories to filter entries by. It needed to work offline, sync online. Mobile first, basic interface, less scrolling, big font, dark text, automatic location tagging that matches the TA route map, periodic data back-up, built-in language checker… all the things I needed to figure out how to do.

This is post 2 of 5.

The notebook guy started it

For a few months now, I’ve been actively thinking about and planning for the biggest trip of my life so far: Te Araroa—or TA. Basically, a long walk from the top of the North Island of New Zealand to the bottom of the South Island.

An essential part of the research is watching YouTube videos of other hikers that have gone before me, to learn from their experiences, to observe their gear, and methodologies and incorporate the lessons in my own planning and preparation. In one such video, I saw a brief scene where a hiker walks into a hut and greets the rest of the hikers who return the gesture—clearly they all know each other. And one of the hikers in the hut looked up from his notebook in which he’d been scribbling something.

It was the first time I saw a video of someone writing in a notebook on TA. Most people use technology—cameras, voice recorders, phones, drones. It’s not a big deal, if you think about it. Journaling is such a common habit and a lot of hikers do it. I just hadn’t seen anyone do it on a five-month endurance hike like TA.

That got me thinking about my own trip and how I’d document my journey. I hadn’t thought about that particular thing before. I loved the idea of writing on a notebook—in fact, I think I’ll still have a notebook. I’d appreciate the sheer analogue-ness of it after a hard day of walking.

But I also knew, within five seconds of watching that video, that I couldn’t rely only on handwritten notebooks to document my trip. One accident on the Whanganui river canoe section and all my notes would be dripping, dead weight.

I could use the Notes app on my phone, I considered. But they’d be so scattered. I didn’t know if I could trust myself to have the discipline to date and location-tag every entry, especially when I might be going through rainy, windy, sleety, scree slopey environments every day.

So I decided to find an alternative option that’d work a bit more… the way I want it to.

As a marketing copywriter who once obsessed with being found online, I’m ashamed to admit this: I didn’t even research what other options might be out there. Instead, like so many people of my generation and industry, I figured I’d just ask Claude.

For months I’d watched people on LinkedIn rave about Claude Code and brag about how they kept hitting their limits. There were proud posts about being on the highest paid plan of Claude Code because they were just building so much cool shit that the peasant version wasn’t enough anymore.

I hadn’t tried Claude Code yet because I didn’t know what I’d build. It seemed rather frivolous to pay for it for the sake of poking it and seeing if it’d poke back.

That clip of a guy writing on his notebook was the impetus I needed. I sat down with Claude Chat to talk it through. What could I build with Claude that could be useful for me on trail, and help me learn the basics of Claude Code and building a solution on it?

So I started experimenting with Claude Code. I’m building something to help me document my trip, and structure it in a way I can look back on and appreciate in the future. But as with any experiment, although the excitement and novelty of it buoys me, I also wonder if what I’m building will truly withstand the trail. I guess there’s only one way to find out.

This is post 1 of 5.