OLD HABITS DON’T DIE HARD - THEY ADAPT
Scattered and Siloed Data
With one of my main photography trips of the year rapidly approaching, my thoughts started to turn to what has become a ritual before I embark on these trips, that being the process of pre-planning. In common with a lot of other photographers, this normally involves consulting various of sources of information, such as maps, sunrise and sunset times, weather forecasts, tidal times and transport links to name a few.
None of these fragments of information speak to each other. Each is contained in its own silo, and the work of stitching them into something of a cohesive picture is down to me. Up until now, my approach has been to use both the old-fashioned method of pen and paper to compile this information into some sort of semblance of an overview of where I am planning to go each day. Prior to departure I then transfer this information to the digital sources of Google Maps which is basically a set of map pins to highlight where I am intending to go each day and Microsoft OneNote, which contains any other relevant information garnered through the pre-planning stage.
A Core Habit That Didn’t Retire
Whilst I appreciate not every photographer will undertake pre-planning and will instead elect to freelance the locations they travel to, for me, preparedness is part of my psyche and was very much ingrained in me during my professional career within the Fire and Rescue Service. From my experience, the outcome of a genuinely difficult incident was very rarely decided in the moment itself. It is decided long before, in the quiet, unglamorous work of pre-planning, the gathering and structured retention of knowledge about the buildings and their surroundings, in the event a crew might one day be called to operate within.
When I began my career in 1989, the primary legislation governing the fire service dated back to 1947. This placed a clear duty on fire authorities to secure efficient arrangements for the provision of advice in respect of buildings and other property in their area as respects fire prevention, restricting the spread of fires, and means of escape.
The 1(1)(d) process as it was commonly known then in Strathclyde Fire Brigade, resulted in a ring binder folder sitting in the appliance containing a number of double sided A4 sheets of paper which was then consulted en-route to an incident as a quick reminder of the relevant information held for the premises in question. Additionally records of hydrant locations and on some occasions, information maps about access arrangements were combined with the crew’s local knowledge to build up a consolidated picture of what we were responding to. This approach had one major weakness, it was only available to the local crew and if they were committed to an incident elsewhere, then the next nearest responders did not have access to this information.
By the time I retired in 2019, all information once held in paper format had migrated to a digital platform which was widely available to not only the local crew but to anyone who was assigned and mobilised to an incident. For me, as an Incident Commander, covering the West Central Scotland, having all relevant information to hand enabled me to build up a comprehensive picture of the situation I was dealing with, to formulate an effective tactical plan.
Closing the door on my professional career hasn't quieted the part of me that thinks in plans. If anything, photography has given that instinct new purpose. The missing piece was always a single, coherent place to gather my thinking and with my next trip only weeks away, a video from Adam Karnacz popping-up in my YouTube notifications arrived at just the right moment to make me reconsider how I prepare.
Adam whose work I have followed for years and greatly admire announced on his YouTube channel that he had created an app derived from his own needs as a landscape photographer and was now making it available to his online community. Seeing his announcement made me think about some notes that I had scribbled down a while ago whilst on a holiday which were some general ideas about cataloguing all my camera equipment for insurance purposes as well as trip preparations and some ideas about a planning tool for my architectural photography.
I never progressed these thoughts that were jotted down as by this time, I was now using Google Maps for the purposes of marking out locations to visit for my architectural photography. In relation to keeping a record of my photography equipment, I just decided to maintain a Microsoft excel spreadsheet and it was as basic as basic can be.
My recent experience with Claude AI in the creation of a bespoke custom-built filter for my website, had me thinking about whether it was possible to create an app to support me on my architectural photography pursuits. There was only one way I was going to find out for sure, so I decided to pose the question to Claude and talk through what I had in mind.
Building the Scaffolding
This decision, I think is worth dwelling on, because I believe it was the single most important decision I made in the whole project. I had no background in software development, so I was acutely aware that I did not know what I did not know. Rather than diving straight into building, I used that conversation to interrogate my own scribbled notes, to have the rough shape of an idea translated into something resembling a genuine architecture (design), and critically, to establish how the interaction between myself and Claude would actually work once real building began. From this conversation I arrived at two options;
· Option A — No-code/low-code composition (a joining together of the siloed information) or
· Option B — A custom-built progressive web app available across various devices
I decided on Option B as everything built inside the app would be stored on my personal storage space and would be all under one roof so to speak. With the decision taken as to the direction of travel, I then set out a few parameters that would govern the development.
The first and most important one, whatever was created had to be at zero cost, no personal finance details to be passed, as I did not want to incur either consequential costs for using any of the features of the app or to have any reoccurring costs such as subscriptions. The only exception to this was the cost to subscribing to Claude Code but this requirement was only for as long as I needed it to complete the build.
The other main parameter that was established before building was that nothing would be considered finished until I had tried it myself, on a real device, in my own hands. I also required every meaningful decision would need to be explained to me in language I could actually evaluate, not simply nod through because I lacked the vocabulary to object.
With the scaffolding in place, I launched Claude Code and so the 3-way relationship began to get to work. I described what I wanted in plain language. Claude (the coordinator) translated this into fully formed prompts and commands which I then passed to Claude Code (the builder). Each confirmed part of the development and subsequent changes were subject to rigorous testing on a development server by Claude Code and by me using my computer, tablet and mobile phone before it was then deployed as live code as part of the app. It was, in every meaningful sense, still my project. I simply no longer had to be the one wielding the tools.
The Idea That Kept On Growing
Over the course of the first few days the app started to take shape, much like a house rising from its foundations, however these first few days were not without some moments where some of the functionality had to be revisited due to either making some further change requests (like rewiring or replumbing a house once built) or from the discovery of a bug which then had to be investigated and a remedy identified and deployed. The first real barrier occurred day 5 into the development and was due to reaching the weekly session limit of Claude Code so I had to wait for 2 days for the limit to reset as a result of the rate of progress that had been made in those first 5 days
What this enforced period of downed tools did engender, was an opportunity to review the app up to this point. I used Claude Code’s 2-day hiatus to note down further tweaks to the functionality, appearance changes and any other bugs that revealed themselves during further testing. By the time Claude Code was back online, the marked off list of design specifications that had been achieved in Days 1 to 5 had now been replaced by another long list of design changes to be progressed as well as dealing with the reported bugs.
During the second phase of development (week 2), the additional changes were incorporated into the app and using the house analogy again, the house was built but I now wanted an extension added. By this time, I had the app deployed online so I began using it to simulate planning my forthcoming trip and was content everything was working as per the initial and the amended design.
At this point, I then thought about what else could I incorporate into the design, so I asked more questions of Claude and Claude Code and from these discussions, further building took place to expand the features further, requiring more testing, more bug reporting and more changes to the code itself. By day 10, I declared the project complete and was content with what my app which by now, I had named as ‘Architrek’, had manifested itself into.
Plan - Explore - Capture (The Role of ArchiTrek)
The app that eventually emerged has eclipsed the initial scribblings on paper that I made a while back. My fundamental approach to my architectural photography is now the foundation on which ArchiTrek stands. My working methods will predominately be grounded from the premise of pre-planning to enable me to work to a structured itinerary. That’s not to say I will just purely go to a location with the blinkers on and not look around where I am, but I wont just pick somewhere at random and aimlessly wander about.
However, decades of operational experience also taught me that no plan survives contact with the field completely unadjusted on every occasion. You must always recognise that there needs to be some flexibility in adjusting any premade schedule when circumstances dictate otherwise unexpectedly. Through its design, ArchiTrek will support these change requirements as the exploration of an area can be quickly changed and amendments to my schedule made without having to revisit the plethora of pre-planning information as I can quickly look at alternative options from within the app and adjust my plan accordingly.
In the longer term, it will also enable me to capture not just the image, but any learning that comes away from each visit. As mentioned in a previous journal, it will support my ethos of sharing this knowledge with others, should they wish to look into their own respective visits to these locations.
Cognitive Growth and Balance
One of my primary goals when transitioning into retirement was to ensure that my days remained intellectually rigorous. I recognised that the benefit of photography was not merely the artistic output, or the physical health benefits, but it also the mental challenges and stimulation from continuing to push my boundaries across these three fronts. This drive for continuous, multi-disciplinary stimulation is exactly what keeps the retirement phase of my life not just rewarding but genuinely engaging.
Insights From The Build Process
As with many of the experiences I have discussed in my previous journals, I take the time to reflect and to identify the key learning points so I can continue to grow as an individual and to share this with anyone for the purposes of supporting their own growth. The creation of ArchiTrek was a totally new experience for me and it was a process I found interesting, challenging and enjoyable as I made my first steps into app development. From this my key learning points are summarised below
Talk Before You Build: The conversation that shaped the idea into a genuine plan, before a single feature was attempted, did more to protect the eventual project than any individual line of code.
Trust, But Verify, Every Single Time: Nothing was ever considered finished on the strength of being told it worked. It was finished when I had tried it myself, on my own device, and seen it work with my own eyes.
Let the Need Lead the Feature: Some of the useful parts of the finished app were not the ones planned from the outset. They were the ones that revealed themselves once the feature before them was already solved.
A Failure Investigated Properly Is Worth More Than One Patched Over Quickly: Every real bug that mattered was found by asking why it had actually happened, not by guessing at the nearest plausible fix.
Free Does Not Mean Limitless: Even a project built at no financial cost still functions inside real boundaries, whether that is a daily data allowance or the honest limits of your own attention. Both are worth respecting rather than assuming away.
The Desk Is Not the Field: Anything that looked finished on a screen in front of me was only genuinely finished once it had survived being tested, on a phone, in my own hand.
Audit Rather Than Assume: A fix applied in one place does not guarantee it reached every place the same problem could be hiding. The only way to know is to go back and genuinely check, not simply hope.
From Concept to Creation
I will admit, finishing this journal, that there is a particular satisfaction in looking at an app I will now use on every single trip and knowing it began as some scribbled lines on a notebook page. There are many great apps out there that encompass many of the functions I now have in ArchiTrek and I am not knocking them one bit, but sometimes you need to get a suit made to measure, rather than buying one off the peg that doesn’t quite fit right. For me the objective was to create something that is tailored to my needs to support my approaches to photography and now the app is fully deployed, that is what I have achieved.
This experience has not made me a software developer, and I have no ambition to be one. What it has made me, is someone who no longer accepts that a gap in my photography is simply something to be lived with, when the tools to close it, patiently and properly, are closer to hand than I ever assumed.
If this journal has piqued your curiosity, I have also made available a full account of how ArchiTrek was built, the accounts, the architecture (design), the honest lessons learned along the way, in the Resources section of this website, in case you are interested in creating your own customised photography tool.
The distance between an idea and its realisation has never been smaller than it is now. What it still asks of you, in return, is exactly what it asked of me: patience, an honest tolerance for getting things wrong before you get them right and the willingness to follow an idea wherever it decides to lead.