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

Not sure I can call it an agent anymore

As a marketer, one of the things I keep hearing over and over again from peers in technology is how good AI agents are. People seem to be running multiple agents that do fantastic work, and particularly the mundane.

Almost a year ago, I tried building my first agent. It didn’t go too well. The technology was intuitive enough but not nearly as simple as it is today. More importantly, I had no idea what I was doing or why I was building the agent in the first place. I didn’t know how to frame what the agent should and shouldn’t do. The scope was surface-level, and I did it because everyone was doing it and not because I had a real need.

I decided then that I’d build another agent only when I have a real problem that only an agent can solve convincingly. I keenly observed what others built and learnt their use cases and reasoning.

Then a few weeks ago, I was working on my notetaker app for my Te Araroa adventure, when the idea came to me.

I’m going off on a 3000 kilometre hike next week, and I’m building this app to serve as my digital notebook, as well as a single database for additional details like emergency contacts, remote towns I need to ship food boxes to, details of my trail crew and an inventory of what they have (food, warm weather gear, extra toothbrushes and sanitisers, etc.), food expenses on trail, and a few other such things.

And so my genius idea was to add agentic capabilities to the app. That’s all I knew. So I asked Claude what agentic things I could realistically build for this project. One thing it said stood out: A resupply agent.

Here’s how it’d work:

One afternoon at a coffee shop, while refilling our bodies and phones, I’d open the app, go to the resupply agent section on the app, and tap a button that says: Check Ahead. 

The agent would only work if I had reasonably stable internet connection, hence the coffee shop.

Once I tap the button, the agent would search for up to five of the next resupply points on the trail, spanning roughly 150-200 kilometres. Then it’d fetch and display the following details:

  • Grocery stores and smaller shops (called dairies in NZ) in that town, including addresses so I can check how far outside the trail marker these shops are.
  • Opening and closing hours for those shops, factoring in any public holidays that might affect operating hours.
  • List of food items I could buy in those shops, considering my vegan and mostly whole food diet.

With this information, I could plan out the next 8-10 days. For instance, if there was a Pak’nSave (large NZ supermarket chain) in two days’ time, then we don’t need to carry too much food until we hit that town. But if the next big shop is 5 days away with only a dairy shop in between, then we’d rather carry 5 days’ worth of food, because dairy shops typically have limited stock.

The agent would play a vital role in helping me organise trail logistics, and it’d be a pretty awesome story to tell. Or that’s what I thought.

Claude Code and I built the thing. Backend seemed solid. But when I tested out the agent, it timed out.

I knew it’d take a bit longer than looking up a predefined list because the agent has to do a live web search. But I hadn’t expected it to time out. After about 5 to 8 attempts, and failures, I asked Claude what could’ve possibly gone wrong.

Then Claude told me: It most likely timed out because the live web search was taking up more processing time than the free version of Vercel allows. Vercel is the backend tool my app is built on, and that platform has a 60-second window for web searches. The agent needs far more than 60 seconds to fetch all the information I asked it to.

So I was at a crossroads. Again. Do I pay for Vercel to increase the time limit? 

It was about US$20/month. I almost said yes to paying—just because I so wanted to see it work and then tell people about this amazing thing I built.

Then my common sense voice spoke up. Realistically, remote towns and cities rarely publish their store times and food lists on the internet. The big ones would have all details linked in Google Maps, and I’ll have Google Maps anyway.

Most importantly, the Te Araroa Trust (which maintains the trail) has a dedicated mobile app that maps out the entire trail, and has detailed notes about every section—including things like shops, water stations, shelters and campsites, honesty boxes, farms, Te Araroa partner suppliers, water crossings, tide info, weather info, and live comments from other hikers who’d gone before me.

This Te Araroa app is the holy grail for all hikers and it’s updated every day. There’s also a WhatsApp group for app support where the developer and the Te Araroa Trust crew are always available to answer questions.

To try and duplicate what they’ve already done, and so much more comprehensively than I ever could, is stupid and vain and a waste of energy and money—even if it was only about $80-$100 over the course of the trail.

As much as I hated admitting it, common sense made sense. So I scaled back my ambitions for the agent. Instead of doing a live search, I got the agent (not sure I can even call it an agent anymore) to lookup the list of towns along the trail and just fetch the next five. No shop names or times, but town names and their kilometre markers, which would still be super helpful for me to plan.

This was easier. I’d already uploaded the full trail map, and the detailed section notes from the Te Araroa website. The app was already using this database to calculate km points and section details for my daily logs.

I was rather disappointed to dial down the agent. I knew the scope well this time and it would’ve added genuine value to the app. I’d finally found a problem worth solving, but the Te Araroa Trust had already solved it, packaged it, and added a bow on top.

—

This is post 4 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

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.