I Couldn’t Find the App I Needed, So I Built It. Here’s What I Learned.
I spent weeks asking ChatGPT, Google, and every tool I could find the same question: if I move to this neighborhood, how close is the nearest park I’d actually use?
No one could answer it well.
Google Maps can route you between two points. LLMs can tell you that Seattle “has great parks.” Walk Score can give you a general walkability number. But none of them answered my actual question: for a given block within a given neighborhood, what’s the walking distance to a meaningful green space?
So I built it myself.
This is the story of how a personal frustration during my move from New York to Seattle became my first public app—built with Claude as a coding partner, shipped as an MVP over a handful of nights and weekends, and designed to answer one specific question that no existing tool answered well.
Why This Existed as a Problem
In my previous articles, I wrote about the framework I used to pick a city and how I used LLMs during the planning process. One of my core criteria was convenient walking access to nature—not “nature exists somewhere in the metro area,” but “I can walk to a real park in under 15 minutes from my front door.”
This mattered to me because of lived experience, not aspiration. Living in New York, I’d discovered that regular morning walks—first through Carl Schurz Park, then Central Park—were one of the highlights of my daily life. I felt measurably better on days I walked. Over time, I realized that a city with great restaurants and nightlife but mediocre park access would be a worse fit for my actual life than a city with fewer amenities but a large park within walking distance.
The problem was that once I had this criterion, I couldn’t evaluate it efficiently.
I did rounds of Google searches. I asked LLMs. I checked existing nature and hiking apps. Nothing quite fit. There are plenty of apps for finding trails or planning hikes—but I wasn’t looking for a weekend adventure. I wanted to know: if I live on this block, can I walk to a good park easily? And how does that compare to the next block over, or the next neighborhood?
That question turns out to be surprisingly hard to answer without building something.
When Finding Is Harder Than Building
This experience led me to a realization I hadn’t expected: for a sufficiently specific personal need, the search costs of finding the right tool can actually exceed the development costs of building one yourself.
Historically, that wouldn’t have been true. Building a map-based web app required professional software engineering skills and weeks or months of development time. The rational move was always to search harder, compromise on fit, or just do the research manually.
But something has shifted. Between vibe coding with LLM tools like Claude, publicly available geographic data, and open-source mapping libraries, the cost of building a simple, personalized tool has dropped dramatically. Meanwhile, the cost of searching—scrolling through apps that almost-but-don’t-quite solve your problem, configuring tools not designed for your use case, cobbling together manual research across multiple sources—hasn’t changed much.
For me, the math flipped. I’d already spent hours on manual research and still didn’t have what I wanted. Building the thing I actually needed took less additional time than continuing to search for it would have.
This has broader implications for anyone building with AI tools. As development costs decrease, the value of complementary capabilities increases—things like judgment about what to build, taste in how it should work and look, and access to the right data. The bottleneck isn’t “can I code this?” anymore. It’s “do I understand the problem well enough to build the right thing?”
What I Built
The concept was deliberately simple: a color-coded map of Seattle showing walking distance to parks, broken down by neighborhood and then by census block.
That’s it. One question, answered visually, at a glance.
Why a map and not a report? I actually tried the text-based approach first. I ran LLM queries and compiled natural language descriptions of each neighborhood’s park access. It wasn’t very useful. Geographic and spatial relationships are fundamentally hard to convey in text. “Wallingford is 0.8 miles from Woodland Park” is less informative than seeing Wallingford on a map, colored green, with a park icon nearby. The visual format communicates distance, relative position, and comparison across neighborhoods simultaneously—something that would take paragraphs to express in words and still wouldn’t land as intuitively.
This connects to a broader principle I’ve been thinking about: the right interface depends on the type of information. Natural language works well for conceptual questions and subjective reasoning. But for spatial data, structured comparisons, or anything where relationships between data points matter as much as the data points themselves—a visual interface is almost always better.
The flow works like this:
Start with the city overview. Every neighborhood is color-coded from green (excellent park access) to red (poor access), scored 0–100. You can see at a glance which areas of Seattle have the best walking access to nature. Hover over a neighborhood and you see its score.
Click into a neighborhood. Now you see the individual census blocks within it, each with its own color and score. This matters because neighborhood averages can be misleading—a neighborhood might score 65 overall, but the blocks closest to a park could be 85+ while blocks on the far edge might be 35.
Click a specific block. You see the address, the nature access score, the nearest park name, the distance, the block area, and a link to view it on Google Maps.
The whole thing follows a principle called progressive disclosure: show the minimum useful information first, then let people drill deeper based on what they care about. For someone just exploring neighborhoods, the city overview is enough. For someone evaluating a specific apartment, the block-level detail is what matters.
How I Built It (And What Was Harder Than Expected)
I used Claude as my coding partner for the entire build. The overall process followed what most people describe as vibe coding: provide a high-level plan, iterate step by step, and make trade-off decisions along the way.
The plan was conceptually simple. I needed three things: data (parks, neighborhoods, geographic boundaries), a frontend (the map interface), and backend logic (calculating distances, generating scores, connecting everything). This is essentially the model-view-controller pattern—data, interface, and logic working together.
Where it got interesting was the trade-offs.
The data layer was the biggest source of real decisions—not because getting data was impossible, but because every data choice had downstream consequences.
First, how do you define a “park”? Is a 2-acre playground sufficient? What about a botanical garden? A greenway? For MVP, I kept it simple: parks above a minimum size threshold, focused on the kind of green space you’d actually walk through for 20+ minutes. That meant leaving out some edge cases, but it kept the scope manageable.
Second, where does the data come from? Publicly available geographic datasets exist, but they come with trade-offs: API rate limits, licensing restrictions, varying data quality, and inconsistent naming conventions across sources. Park data uses one taxonomy. Neighborhood boundary data uses another. Census block data uses yet another. Making these work together required judgment calls—how to define neighborhood boundaries, how to handle edge cases where a block spans two neighborhoods, what to do when data sources disagree.
Third, how do you serve the data? Making live API requests for every user interaction would be slow and fragile—and could hit rate limits fast if multiple people use the app simultaneously. So I downloaded the data upfront and serve it locally. For an MVP with a small user base, this works well and keeps the experience fast. Scaling would require a different approach, but that’s a future problem.
The frontend was where taste mattered most. The color scheme, the scoring scale, the level of detail in the popup, the decision to show census blocks rather than arbitrary grid squares—these are all judgment calls that determine whether the app feels useful or confusing. No amount of coding skill replaces knowing what the user (in this case, initially me) actually wants to see.
The backend logic surfaced subtle complexity. Distance calculations between geographic points aren’t as straightforward as they appear—coordinate systems, projection methods, and the difference between straight-line distance and walking distance all matter. For MVP, I used a reasonable approximation that’s good enough for “is this a 5-minute walk or a 20-minute walk?” If I need higher precision later, I can refine it.
Where Vibe Coding Helped—and Where It Didn’t
Building with Claude as a coding partner was significantly faster than building alone would have been. The LLM was particularly good at generating boilerplate code for map rendering and data processing, suggesting library choices and architectural patterns, helping debug issues when I could describe the problem clearly, and handling repetitive tasks like data formatting and conversion.
Where it struggled was when problems required context that’s hard to express in a prompt. For example, I hit a rendering bug where the frontend wasn’t displaying blocks correctly. Claude tried multiple fixes, each of which introduced a new problem—we went in circles. What eventually broke the loop was me suggesting we use browser developer tools to inspect the actual errors, which gave us concrete diagnostic information to work with. In another case, a more capable model release solved a problem the previous model couldn’t crack.
This reinforced something I’ve come to believe through this process: understanding computer science fundamentals matters, even in a vibe coding world. Not because you need to write every line yourself, but because when something breaks—and it will—you need enough understanding to diagnose the problem, ask the right questions, and evaluate whether the LLM’s proposed fix makes sense. If you abstract away all understanding of how the system works, you’re stuck the moment something goes wrong.
That said, I want to be honest about the tradeoff: for a simple, single-user application like this, the fundamentals matter less than they would for a production system serving thousands of users. The stakes of a bug are low. The complexity is manageable. If you’re building something for yourself and learning as you go, vibe coding is a remarkably effective way to do both simultaneously. Just know that the further you scale—more users, more data, more features—the more that underlying understanding pays off.
Lessons Learned
Build for yourself first, then share. I built this because I genuinely wanted it. That meant I understood the problem deeply, had strong opinions about what the solution should look like, and could evaluate quality without user testing. Solving your own problem is the fastest path to a useful product.
Start with one question. The app answers one question: how walkable is the nearest park from this location? Every feature decision flowed from that. When I was tempted to add hiking trail data, transit overlays, or restaurant proximity, I asked: does this help answer the core question? If not, it’s post-MVP.
Data is the real bottleneck, not code. The most time-consuming part wasn’t writing code—it was finding reliable data sources, understanding their limitations, reconciling different taxonomies, and making judgment calls about quality. As vibe coding makes development easier, data access and data quality become key differentiators for applications.
The right interface matters more than the right model. I tried answering this question with LLMs (natural language), with manual research (spreadsheets and notes), and with a visual map. The map won—not because it has more information, but because it presents spatial information in the format humans process most naturally. Choosing the right interface for your information type is a design decision that no amount of better AI can substitute for.
Ship the MVP, then iterate. The current version has rough edges. The scoring could be more sophisticated. The data could be more comprehensive. The styling could be more polished. None of that matters as much as having a working tool that answers the core question. Everything else is refinement.
What’s Next
The immediate plan is to continue refining the app—improving the interface, exploring additional cities, and seeing whether other people find it as useful as I do.
But the bigger takeaway from this experience is about a shift that’s happening in who can build useful tools. A few years ago, building a map-based web application required a team of engineers. Today, a product manager with some CS background and an LLM coding partner can ship a functional MVP in weeks.
That doesn’t mean the engineering is trivial. It means the barrier to entry has moved. The scarce resource is no longer “can you code it” but “do you understand the problem well enough, and do you have the judgment to make the right trade-offs?”
For me, this started as solving my own problem. It turned into my first public app. And it taught me more about building products than years of managing them from the other side of the table.
The app is available here: nature-access-map.
This is the fourth article in a series. Article 1 covered using Claude Code for financial planning. Article 2 covered the framework I used to evaluate potential cities to move to. Article 3 covered where LLMs helped and failed during the planning process.