Learning AI by Building
Creating a location intelligence platform for discovering dispersed campsites, scenic routes, and photo-worthy landscapes using terrain, data synthesis, and AI-assisted scoring.
RoamsWild
RoamsWild began as a learning project to explore how AI and modern APIs could power more intelligent outdoor exploration beyond static pins and outdated user reports.
Rather than working on a small or hypothetical problem, I chose a complex, real-world domain I know deeply: road-based travel, dispersed camping, and landscape photography. Using modern AI tools as a build partner, I designed and implemented an intelligent exploration app that helps people make better decisions in the moment — where to go, when to go, and why it’s worth it. The project reflects my process of learning by building, treating data, scoring logic, and human judgment as core design materials.
Project Overview
Objective
The primary goal of this project was to learn how AI tools and modern APIs could extend my capabilities as a Product Designer. Rather than treating AI as a novelty feature, I used it as a practical build partner to help me design, prototype, and implement systems that would normally require an engineering team. Large language models supported rapid exploration of system architecture, API design, and data transformations, allowing me to move from ideas to working implementations much faster than traditional learning paths.
This case study focuses less on a polished final product and more on how my role evolved as I learned to design and build AI-informed systems end to end.
Tools
Claude Code
Loveable
Chat GPT
Github
Supabase
Vercel
Procreate
Notion
Choosing a Problem
I intentionally chose something that was personal to me but still a real problem, and something I would be excited about. I am constantly on the road and traveling outdoors - and I mainly camp out on public lands for overlanding or offroading trips. So I combined a few instances that were part of a complex domain:
Outdoor Travel
Dispersed Camping
Landscape Photography
From experience, this space has messy and imperfect data and requires judgment, not just retrieval, which ensured I was learning hard things rather than building a simplified or artificial example.
Outdoor and road-based travelers rely on static apps, outdated user reports, and guesswork about conditions and quality. As a user, I’ve experienced decision fatigue, wasted time, and many “good on paper, bad in reality” locations.
Current tools that support this experience are fragmented and time-consuming, often requiring users to cross-reference multiple apps:
So I thought…
How might I design a system that helps people make better decisions, not just find places?
The Beginning
The start of this project wasn’t planned. I started with a vague prompt that was more about exploring possibilities than building a specific product. It wasn’t until I had Claude, Supabase, and a local development server running that I realized I could actually build something end to end.
I began by clarifying three things:
Who this was for: road-based travelers and/or photographers navigating public lands
What decisions they struggle with: land and road access, terrain quality, weather timing, and confidence
What success looked like: fewer but better and smarter recommendations, explained clearly
Takeaway #1: Start with some kind of plan or you will spend a lot of time regressing or redoing work. Seems obvious, but its easy to get carried away with ideas.
The initial output was extremely incomplete because I hadn’t clearly defined what I was trying to make. Features were vague, and some flows didn’t make sense from a product perspective. As I spent more time experimenting and evaluating public APIs, the project began to take shape into something more intentional.
The Foundation
Once I had something more concrete, I intentionally shifted focus back to design quality. I created a style guide, improved consistency, and refined core interaction patterns so the product didn’t feel like a purely technical experiment.
Takeaway #2: Might seem obvious but don’t forget you still need to design. Otherwise it looks kinda of like everything else AI might produce. Or like an Engineer designed it.
From Ideas to Systems
I started with simple heuristics to predict potential dispersed campsites by combining public land data with road networks, identifying dead ends and intersections where campsites often appear.
From there, I designed and built systems that:
Score terrain lighting quality using sun azimuth and weather data
Evaluate scenic potential and access confidence
Factor in timing relevance for photography
These systems powered a photo spot–focused exploration experience, with reasoning intentionally exposed in user-friendly language
Takeaway #3: With the range of APIs available today, deriving new data can unlock entirely new product experiences.
Designing the Intelligence Layer (AI + APIs)
Instead of relying on popularity, static information, or user reviews, I focused on defining what I wanted the product to consider when making a recommendation. I outlined the kinds of signals that matter in this context, like road type, access, land ownership, weather, and elevation profiles — and then used existing APIs and lightweight models to turn those inputs into ranked results. Initially it was less about inventing algorithms and more about deciding what factors should matter, how they should be combined, and how the output should make sense to a person using the app.
To build this as a solo designer, I used large language models as a development partner — specifically Claude code to help prototype API endpoints, generate feature logic, and iterate on scoring approaches quickly. The AI tools accelerated learning and implementation, but the model design, feature selection, and weighting decisions were driven by product intent: surfacing recommendations that users could understand and trust, and using my knowledge of the space to extensively debug results.
Rather than treating RoamsWild as a collection of tools, it become more of a set of decision-support systems. Each feature began with a specific question — all things that I have experienced while out on the road: How to predict better light, how to interpret weather for photography, how to surface potential campsites without relying solely on user reports.
Key Product Experiences
The biggest pain point I wanted to solve was decision overload. When traveling, the problem isn’t a lack of options—it’s evaluating which ones are actually worth it.
Photo Weather Conditions
Standard weather apps show data; photographers need timing insight. This service evaluates cloud cover, cloud level, and wind during sunrise and sunset windows to determine whether conditions are promising. The result is a simplified signal with brief reasoning, helping users decide if the sky is likely to be clear, dramatic, or somewhere in between.
Surprise Me
Picks a random outdoor region for you based on your location, scoring candidates by public land access, trail density, campsites, and biome diversity, then enriches the result with a scenic drive anchor from Overpass API.
Best Hikes Today
finds nearby hiking trails via Google Places and ranks them for right now using real-time weather from NOAA, sun position, crowd levels, and trail effort to surface the best hikes for today's conditions.
Photo Scout
Analyzes terrain elevation data around a location to find optimal sunrise/sunset photography spots, identifying dramatic terrain features, calculating sun-terrain lighting geometry, verifying shadow-free sightlines to determine shooting locations.
Takeaway #4: Avoid getting carried away - focus on baseline experiences before expanding. Harder than it sounds when there is so much potential.
Challenges
LLMs can be wrong, and they can be wrong a lot
Working with AI tools introduced a different set of challenges than traditional design work. Large language models are powerful, but inconsistent, which meant anything generated needed careful review, debugging, and validation. AI outputs were a starting point, not a source of truth.
Designing isn’t the easiest while building
Claude is actually really good at determining UX with little guidance. Sometimes if you are too specific it has a harder time creating something good. It does have a hard time with consistency, and changing the design after the fact takes time and effort.
Things can get messy fast
As the project evolved, complexity grew quickly. Without clear structure, logic and experiments could become messy, forcing me to slow down, document decisions, and be more intentional about what I was building and why.
AI tools = Engineers ≠ Designers (In my Opinion)
I also learned that AI tools behave more like engineers than designers. They can implement ideas, but they lack judgment, consistency, and taste. Early outputs were often functional but visually basic or misaligned, reinforcing the need for strong design direction.
Theres a lot to consider, that you might not consider
Finally, the project surfaced constraints I don’t normally encounter in design-only work; API response times, error handling, and packaging the app for real use. These considerations directly affected the experience and pushed me to think beyond interfaces and more holistically about the system, and taught me a lot.
You can do a LOT very quickly
I built the base of this app in a few days. In less than 24 hours I had a working trip planner with a full database and a live URL. The power is overwhelming and has so much potential.
The ethical dilemma of using AI
As an avid outdoorswoman, I struggle with the use of AI given its effect on the environment. Its a back and forth challenge of seeing the potential but also knowing that its likely going to cause more harm than good in the long run.
Outcomes
RoamsWild began as a passion project, but it quickly became a real product with live infrastructure.
In its initial build cycle, I:
Designed and shipped a working trip planner and derived campsite discovery system in ~2 days
Live deployed the application with authentication, database structure, and API integrations
Established a scalable schema for locations, derived signals, scoring, and confidence modeling, and started building my own database of information
Built foundational services for terrain-based glow analysis and contextual weather evaluation
Building this reinforced that fast tools don’t replace product thinking, or design. Most of the real work was narrowing the scope, simplifying logic, and deciding what actually improves the experience and provides actual results, instead of just sounding impressive.
Whats Next?
Since this is something I would personally use and have a few friends interested, I am working to get a more stable release ready (I didnt follow my takeaways and got too ahead of myself with creating new features).
I have created a plan and a backlog to continuing working on this as a passion project and keep discovering more and more I can do with it.
Offline support
Real-time validation
Community moderation model
Advanced explainability layer
Mobile-native iteration
