I recently used Claude, Anthropic’s large language model (LLM) to build a personalized app to help me plan future photographic projects. I was delighted with how it went.
Since I have no coding expertise, I chose Claude because of its growing reputation for vibe coding — using natural language prompts to describe the desired capabilities of an application, leaving the LLM to generate the required code.
Here is a brief description of my experience of vibe coding with Claude, and the outcome “we”achieved.
Objective
A personalized app to determine the date and time when the sun will set at a specified point B on the horizon, as viewed from a specified vantage point A.
Example use
Photographing the setting sun near the New Point Loma Lighthouse, from a camera position on Ocean Boulevard in Coronado.
Keith’s prompt
I would like to build a program that would help me with a photography project I am working on. I want to specify a vantage point A, from which I will take a photograph, looking towards a second specified point B on the horizon. Once I have specified these two points A and B, I would like the program to tell me on what date and at what time, the sun will set behind the second specified point B.
Claude’s response
Now I’ll build this — a sun alignment calculator that finds dates when the sun sets along a specific bearing from point A to point B. This requires solar position math (azimuth calculations) based on GPS coordinates.
Here’s your Solar Alignment Photography Planner.
Output
For the sake of brevity, below are screen shots of the final product. Claude chose the format and color palette of the graphical user interface (GUI). It has input fields to specify locations A (camera) and B (target on horizon), as well as year, time zone, and angular tolerance (in degrees).
The output is a set of dates and times when the sun will set behind the target point on the horizon, as well as a qualitative assessment of how good the alignment will be.
For a full account of my dialog with Claude, which went through a number of iterations, including an example of Claude fixing a bug in its own code, continue scrolling.
Observations
The final version of the app allowed me to specify the location using either latitude and longitude figures, or the new “What3Words” geolocation system.
The calculator identified three dates in February and three dates in October when the setting sun would be in alignment with the bearing I specified. This makes sense, because the setting sun passes the specified point B twice during the year the year.
The first version of the app correctly calculated the dates, but not the times. When I pointed this out, Claude realized there was a coding error — a missing “-” sign in one of the lines of code. Once this was fixed, both dates and times were correct.
What I learned
- Think carefully through what you want to do
- Compose an off-line prompt which is clear and detailed
- Ideally, build into the prompt a worked example
- Check that calculations or results are correct
- Iterate where necessary to optimise the program
- Save the final product, along with original prompt
Why not try this yourself?
If you have digital tasks you undertake repeatedly, why not build a personalized app to help you do it more efficiently? Or if you find yourself looking up the same information time and time again, why not build an app to speed up the process.
Building apps that perfectly meet your specific need is now possible, with Claude.
The rest of Keith’s dialog with Claude
Here is how the conversation with Claude continued, resulting eventually in an optimized, fully functional app.
Claude: Here’s how to use it:
Setting your points:
- Type a place name in the search box and hit Find to geocode it, or enter coordinates directly, or click on the world map to drop pins
- Use the 📍 button to place Point A at your current GPS location
What it calculates: Using NOAA’s solar position algorithm, it computes the sun’s azimuth angle at sunset for every day of the year, then finds every date where that azimuth matches your A→B bearing within your chosen tolerance.
The results table shows:
- The exact date and day of the week
- Local sunset time on that date
- The sun’s precise azimuth at that moment
- How closely it matches your bearing (offset + quality bar)
Tips for best results:
- A bearing must point into the western sky (roughly 180°–360°) for a sunset alignment — if your bearing faces east, you’d be looking for a sunrise alignment instead
- Use ±1° tolerance for precise shots; ±1.5°–2° if you want a wider window
- Set your correct timezone in the settings so the times are accurate for your location
Keith: Can you adjust the calculator to use the ‘what three words’ geolocation system to specify points A and B? I know the location of the two points of interest in that system.
Claude: Good — I can see the key details. The free plan only includes autosuggest, while convert-to-coordinates requires a paid plan. I’ll build the tool so users enter their own API key, use the convert-to-coordinates REST endpoint directly, and also include the autosuggest feature for input validation. Let me update the file now.
Read current file to update it
Read current file to update it
Rather than patching inline, I’ll rewrite the file cleanly with the what3words integration built throughout:
Created 2 files, ran a command, read a file
Created 2 files, ran a command, read a file
The tool has been updated with full what3words integration.
Keith: Thanks! I tried the calculator and the dates look correct, but the times do not. They are morning times, whereas the sun sets in the evening. What might be wrong?
Claude: This is a classic sign that the longitude sign is reversed somewhere in the sunset time calculation. The NOAA formula computes sunset as minutes from solar noon, and if the longitude has the wrong sign, it shifts the result by roughly 12 hours — turning an evening time into a morning one.
The most likely culprit is this line in the code:
const sunsetUTCMins = 720 – 4 * (lng + ha) – eqTime;
For sunset, the hour angle ha should be subtracted (not added), because the sun is west of the meridian at sunset. It should read:
const sunsetUTCMins = 720 – 4 * (lng – ha) – eqTime;
The + ha was intended to handle the sign implicitly (since sunset ha is positive), but combined with how the azimuth is then mirrored with 360 – az, it introduces the 12-hour offset you’re seeing.
Keith: Can you please make this change and update the program? Thank you
Claude: Done — one character changed, lng + ha → lng – ha. The sunset times should now fall correctly in the evening. Let me know how it looks!
Keith: It works correctly now! Thank you.
Claude: Glad it’s working! It’s a satisfying tool to have for photography — there’s something special about planning a shot, weeks in advance, and then having the sun drop exactly where you hoped. Good luck with the project!
Keith: Can I export this calculator somehow, and save it, for example on my computer desktop, or should I save it somehow within the Claude app?
Claude: The file is already a self-contained HTML file, which is great news — it needs no server, no internet connection (except for the what3words API calls), and no special software to run.
To save it to your desktop: Just click the download button on the file attachment above, and save it wherever you like — your desktop, a project folder, etc. Then simply double-click it to open it in any web browser (Chrome, Firefox, Safari, Edge all work fine).
Leave a Reply