What I learned building (and rebuilding) Yorkshire Adventure
2026-10-15
Why I built it
Back in 2023, I was an engineering manager leading frontend teams, but I was conscious I'd barely written any frontend code in my life. Worse than that, I was in the middle of a transformation effort to migrate all of our apps to React Native, and I had zero experience in mobile engineering. I've always felt that the fastest way to lead people through change is to understand more about living the change yourself, so I challenged myself to get my own mobile app onto both app stores.
I'd recently moved to the wonderful town of Knaresborough and was getting fascinated by its history, so I settled on a treasure hunt app where people could explore and learn about the town.
This was also the early days of AI-assisted development. I got myself a GitHub Copilot licence, and the magic new world of autocomplete was a huge accelerant for writing in a language that was new to me.
That was the start of a three-year journey: a game built in a weekend, months of app store faff, getting kicked out, a rebuild with Claude, and a haunted trail with an AI narrator that now sounds scarily human. Here's what I learned along the way.
Death by app store
It was fun to get back into coding and building (little did I know just how much easier AI would soon make it to build without coding at all!)
I had a working version of my game after one weekend at my laptop. I was thrilled! I'd be on the app store in no time! This is easy, I don't know why mobile engineers think it's so hard!
And I did finally make it onto both stores... 8 months later. Android build fixes, performance issues, obscure bugs, screenshots for deprecated iOS devices, finding 20 people to test my Android beta, etc etc. It was painful. I learnt a lot though, and I now feel I can lead mobile engineering teams with a little more empathy.
In fact going live took so much effort that I crawled over the finish line with little enthusiasm left for the marketing and maintenance a living app actually needs - not with an exciting day job and family life to contend with too. Usage was light, and after a year or so without any updates, the app got kicked out of the app stores. The learnings lived on, but the app itself did not. RIP 🪦
Resurrection
This year, my teams went through another major shift. Not to mobile development this time, but to AI-native engineering, with harnesses, agents, spec-driven development and all that good stuff... things have come a long way from magic autocomplete!
So, time to roll up my sleeves again and bring my app back to life, with Claude Code at my side and renewed enthusiasm to make something that will live on - this time as a web app, without app store maintenance and licences to worry about.
Test what's there first
I remember Mark, my first tech lead as a software engineer, telling me that the first thing to do in any major refactor is test what's already there. Sound advice, so that's what I did. Claude helped me set up UI and integration tests as step zero, before we used Superpowers to spec out the full migration.
With this being a game you play in real life, walking around town with GPS tracking, automated testing is quite difficult, so I didn't invest in it the first time around. Looking at the commit history, you can tell!
Unfortunately, now that Claude writes them, my commit messages are a lot more boring to look back through.
According to Boris Cherny, who created Claude Code, verification is the most important thing to get right when building with agents, and I've seen the same lesson on my other ongoing project, Juggle Perfect. It's an augmented reality game played with real-world balls, so testing started out entirely manual, and it wasn't until I built a synthetic testing framework that Claude was able to help me fix a load of bugs that I'd been stuck on. I might write another blog post about that soon...
Good practice is cheap now
The refactor went well - I was back up with a web version within a day. My main observation was how much cheaper it is to bake in good practice from day 1, even on hobby projects. First time round, coding by hand on my own, I didn't bother with extensive testing, a staging environment, CI/CD, vulnerability scanning, etc. This time I had them in place in no time, so I can now maintain the project with a lot more confidence.
The one thing I did do well the first time around was to use architecture decision records. I've been a fan since reading about them on the ThoughtWorks Tech Radar 8 years ago, in my early tech lead days, and it's nice to see them become more popular in AI-focussed teams, where context really is everything. A few of my old decisions were worth reminding myself of. I'd made it as low maintenance as possible, so the only back end is an AWS S3 bucket, which is still going strong years later. And the app is trail agnostic: everything specific to a trail is config pulled from that back end. That's a big part of why the move from mobile to web took a day, not weeks.
A new trail: AI and design
When I went live on web, I let some local friends and the charities I'd worked with know it had been relaunched. That led to the opportunity to build a new 'haunted' trail alongside Knaresborough Youth Council. I do love a good ghost walk, and it was a chance to do some product-focussed engineering after the re-architecture.
By now I've done a few bits of frontend work in hobby projects and hackathons, and in my experience, Claude is really not great at design.
At a FanDuel hackathon this summer we spent hours iterating with Claude and more design-focussed AI tools (Figma Make etc) but couldn't get things looking quite right... then we asked an actual professional human designer for help and she levelled things up immediately.
Tip 1: give it visual references
Current models work far better with visual references than with prompts, so for the haunted theme I researched other spooky experiences online and gave Claude lots of reference material. We wanted the trail to work for ghost walk enthusiasts as well as families, so finding a spooky balance somewhere between Casper the Friendly Ghost and Ju-On: The Grudge was important!
Tip 2: keep humans in the loop
The other advice I'd give for any product build is to work with real people and get feedback early. I built several designs on a staging environment, switchable from a debug settings menu, and went through them at a Youth Council meetup before settling on the right one.
The narrator
One of the biggest improvements to the app is the narrator we've added. I genuinely don't think it would have felt this good even a few months ago.
With a few modifiers in ElevenLabs' new v4 model, I got a Yorkshire storyteller who changes his tone and atmosphere through each story to build tension and dread, then relieves it with light-hearted, playful notes at the right time.
That's what every AI voice generator I'd tried before was lacking. You could make it sound like a person, but not like a proper storyteller - at the hackathon I mentioned, you could really tell which submissions were AI-generated. The new ElevenLabs model really does seem human. Scary, but impressive.
At Leeds Digital Fest a couple of weeks ago, several speakers gave advice on being a tech person in an AI world: keep reimagining and reassessing what's possible, even go as far as building things you think aren't possible, and just try it.
I knew it would be possible, but I didn't think it would be as good as it is, and as easy as it was to implement. So it's something I need to keep pushing as I build new things.
Staying close to the change
A bit of advice I'll leave you with if you're an engineering leader: the fastest way to understand a change in the tech landscape is to try living it yourself.
First time round, living the change taught me empathy: shipping a mobile app is much harder than it looks. This time it taught me the opposite. The things that used to be expensive, like testing, CI/CD and good documentation, are now cheap. Whilst I have always held a high bar, as an engineering leader you're always weighing up tactical vs strategic decisions, where to save cost and effort. The cost equation has changed for sure.
What's still hard is the human stuff: design, real user feedback, knowing whether you're building the right thing. That's where I want my teams spending their time.
And if you're ever in Knaresborough, come and play! There are three trails - the original Historic Knaresborough, plus the haunted Town and Dark trails - all free to play at yorkshire-adventure.co.uk, with the option to support Knaresborough Youth Council along the way.