#9: Trip Atlas

Description:
Trip Atlas web-based app was created based on the real life scenario of an individual photographer researching photographic locations for an upcoming trip to several international cities. I conceived, ideated and built the app to provide locations, descriptions, sample photos, geo-related data, access information, equipment recommendations, and places to eat nearby.

Trip Atlas demonstrates the viability of AI-assisted development for building production-ready web applications, with iterative refinement guided by continuous testing and user feedback.

URL: https://www.tripatlas.app

AI Tools:

• Claude Sonnet 4.6
• GitHub CoPilot
• v0 by Vercel
• Loveable

Early Ideation

The initial concept for Trip Atlas began in Claude Code, where the foundational architecture and feature set were defined through conversational AI development. The codebase was then ported into Vercel's v0 platform to leverage its UI generation capabilities and seamless deployment pipeline.

Core Screens Identified:

  • Landing page (logged-out state with Sign In / Create Account options)

  • Account creation via email authentication

  • Trip management page (list of user's trips)

  • Trip spots page (photography locations within each city)

  • Individual spots (details about each location, access requirements/hours, recommended equipment)

Key Design Decisions:

  • No AI-generated imagery - All sample images sourced from real photography APIs to maintain authenticity

  • Photographer attribution - Every image displays proper credit to respect intellectual property

  • Image sourcing evaluation - Compared Flickr API (requires commercial agreement, variable licensing) versus Google Places Photos API (pay-per-request at $7/1,000, location-specific results); selected Google Places for superior location relevance

  • POI identification accuracy - Implemented validation to ensure photography spots return actual, visitable locations with correct coordinates and addresses

UI Bake-off: Loveable vs v0

To evaluate the best tool for rapid UI prototyping, parallel designs were created in both v0 and Loveable. This comparison focused on visual fidelity, component quality, and alignment with the dark-themed photography aesthetic required for Trip Atlas.

The bake-off specifically examined the hero image header treatment, with Loveable proposing a full-bleed background image approach. While visually striking, this approach was ultimately evaluated against v0's component-based design system for long-term maintainability and responsive behavior.

Loveable concept

UI Revisions and Functionality Iterations

Development progressed through multiple revision cycles, each informed by hands-on testing and design refinement.

Footer addition
Added persistent footer with copyright, version badge, and About drawer
Provide app information and professional polish

Archived badge positioning
Moved from overlapping 3-dot menu to left-aligned on trip cards,
Prevent UI element collision

Privacy messaging
Added "You will not be spammed" text to auth screens
Build user trust during account creation

Spot page loading state
Replaced "Location not found" flash with skeleton loader
Improve perceived performance

Button text clarity
Changed "Add Spot" to "Add a custom spot"
Clarify user action intent

“About” drawer interaction

UAT Process

A structured User Acceptance Testing (UAT) process was established to validate changes before deployment. This included systematic verification across affected screens and explicit rollback procedures when implementations didn't meet requirement

Troubleshooting with the Agent

UAT Protocol established:

- Agent performs UAT verification after each implementation

- Multi-location changes verified across all affected screens

- Explicit confirmation required before PR merge

Reported bugs and issues were identified and fixed, with explanations for each

GitHub Integration

Connecting the v0 project to GitHub required learning the workflow for exporting a v0-created project into a version-controlled repository. This enabled proper pull request workflows and collaborative development practices.

Process

  1. Create repository in GitHub (v0-photography-spots-research)

  2. Connect v0 project to repository via Settings panel

  3. Changes in v0 automatically push to a feature branch

  4. Pull request created for review before merging to main

  5. Branch naming convention: v0/[username]-[id]

This integration established a professional development workflow, allowing changes to be reviewed, tested, and merged systematically rather than deploying directly from the v0 environment.

A/B Comparison: Tab vs List Approach

Tab approach

  • Cities displayed as horizontal tabs

  • Spots shown in grid below selected city tab

  • Compact, app-like navigation feel

  • Better for users with few cities per trip

A toggle-based tool for comparison was implemented to evaluate two different information architecture approaches for displaying trip content. The Tab approach, originating from the Loveable design exploration, was compared against a traditional List approach.

Ultimately, the Tab approach was selected for the current implementation, providing a cleaner mobile experience while maintaining desktop usability.

List approach

  • Cities displayed as expandable sections

  • All content visible through vertical scrolling

  • More traditional web pattern

  • Better for users wanting full trip overview

Solving the Image Expiration Problem

During beta testing, a critical issue emerged: spot images stopped loading after 24-48 hours. Investigation revealed that Google Places Photo API returns temporary URL references that expire quickly, rendering stored image URLs useless.

Problem discovery

  • Trip created in March showed broken images weeks later

  • Database contained valid-looking URLs, but Google had expired the references

  • This affected all spots across all cities

Option 1: Refresh on view
Approach: Fetch new URL each time a spot is viewed
Trade off: Ongoing API costs; added latency

Option 2: Vercel Blob storage
Approach: Download and store actual images permanently
Trade off: One-time implementation, minimal ongoing cost

Option 3: Do nothing
Approach: Accept broken images
Trade off: Poor user experience

Implementation

Vercel Blob was selected for permanent image storage. The /api/flickr-images route was updated to download images from Google Places and upload them to Vercel Blob, returning permanent URLs. A migration script refreshed all 40 existing spots of the test trip: Edinburgh, Amsterdam, Barcelona and Dublin

Cost analysis

  • Storage: ~$0.02-0.25/month depending on scale

  • No ongoing API calls for image retrieval

  • Images never expire

Future roadmap

Trip Atlas is currently in beta with several planned enhancements to expand functionality and improve user experience.

Route Planning & Optimization

The most ambitious planned feature enables users to build an optimal route for visiting photography spots within a city. Users select their starting location (hotel or accommodation), choose which spots to visit, and pick a transport mode (walk, drive, or public transit). The app then calculates the most efficient path between spots, factoring in travel time and optimal photography conditions like golden hour and blue hour. Start time recommendations help photographers arrive at each location when lighting conditions are ideal.

Offline/PWA Mode

A Progressive Web App implementation using Serwist (service worker) and IndexedDB will enable users to access their trip data without internet connectivity. This is particularly valuable for travelers accessing their itinerary in areas with limited connectivity.

Print & Download Itinerary

Users will be able to print or download their trip itinerary as a clean, ink-friendly PDF. The output will include trip name, dates, cities, and for each spot: name, address, description, recommended times, and equipment suggestions.

Image Loading Optimization

Currently, each spot fetches 2 images from Google Places API. A "Load more photos" button will allow users to request additional images on demand, balancing visual richness against API costs ($7 per 1,000 requests).

Nearby Spots Discovery
While viewing an individual spot, users can optionally see additional photo-worthy locations within a configurable radius that didn't make the curated list. This feature is controlled by a user preference toggle, keeping the UI clean by default while giving photographers the option to discover bonus opportunities.

Trip Atlas screens

Trip screen

Spot screen

Was this a successful experiment?

While this goes beyond the established experiment scope, it was a successful AI-assisted development of a production-ready web app. I was able to use this throughout my travels as a way to plan, find and manage my daily shots.

What surprised me?

The relative speed of the UI design from v0 as well as some of the pattern suggestions it put forward during the iterations.

What did I not expect?

The amount of time I spent troubleshooting was a painful. I did not expect to spend so much time (and token resources) on bugs. Ultimately I learned how to better interact with the agent in order to generate a more successful, positive output. I also learned that persistent UAT is necessary to avoid larger issues later.

What would I have done differently?

Since this was my first vibe coded app, there are many things I would have done differently, starting with how I had the agent approach the work. I would have broken it down more and started the UAT process at the beginning. Ultimately, I’ve got a better handle on the process and steps required to build and produce.