Why I Focused on the Han River Instead of Expanding Nationwide
I chose a scope I could verify directly and explain responsibly over a broader park app.

While building Hangangjari, I once wanted to give it a larger name.
If the first feature is parking checks, the next imagination comes naturally. Could it work for other parks? Could it expand beyond Seoul? Would the app look larger if it had a name broader than Hangangjari? These ideas grow easily in personal projects.
A nationwide park outing app. An app for checking parking availability and surrounding information anywhere you go on weekends. An app covering urban parks, national parks, and local government parks, not only the Han River.
As an idea, it sounded plausible. The inconvenience I felt at the Han River repeats elsewhere. People want to know whether to bring a car, whether parking exists, whether real-time remaining spaces are visible, and whether there are other options after arrival.
So I researched whether nationwide expansion was possible. I looked at national standard park data, national parking-lot standard data, local real-time parking APIs, and direction APIs. I even considered names like “Outingjari” instead of “Hangangjari.”
The more I researched, the more the answer moved the other way.
It looked possible to gather park lists and parking-lot lists nationally. But users did not want lists. They wanted to know whether they could take the car right now. To answer that, the app needed real-time remaining spaces, updated time, operating restrictions, whether a lot was dedicated to the park or merely nearby, and usable entrances for navigation.
With public data alone, it was not realistic to speak reliably about real-time parking for every park in the country.
Some data had only park lists. Some had parking locations and total capacity but no real-time availability. Some regions had real-time APIs, but not every parking lot was connected. Automatically matching parks to parking lots was also riskier than it looked, because the nearest lot is not always the park’s usable lot.
In the end, nationwide expansion was not a matter of adding more features. It was a question of how far the app could make claims users should trust.
That conclusion was disappointing. A wider name makes an app look bigger, and larger data lists look impressive. In reality, the promise became blurrier. The first promise Hangangjari needed to keep was not “it knows many places,” but “it shows information needed before and during a Hangang visit in a trustworthy way.”
Three problems became visible through research
When reviewing nationwide expansion, the first thing I checked was whether data existed. Park lists, parking lists, and location data were easier to find than expected. The problem was that having a list does not answer the user’s question.
The first wall was real-time availability. Hangangjari’s core question is close to “Can I go now?” A static parking-lot list cannot answer that. Total capacity helps, but whether spaces actually remain on a weekend afternoon is a different problem.
The second wall was matching. A parking lot near a park is not always a park parking lot. It may have a different entrance direction, be reserved for a specific facility, or have poor walking access. Automatic matching looks easy but can fail at the exact moment a user drives in.
The third wall was explanation responsibility. Expanding nationwide means continually explaining that some regions have real-time data, some have only basic data, and some have no data. That could become a good app if done well, but it was not what I wanted to take on for the first public release.
I chose a trustworthy scope over a broad name
At first, increasing locations felt like natural growth. But when I tried to write an App Store description, I kept getting stuck.
Shows real-time parking availability for every park nationwide.
That was a larger promise than I could keep. The following was more honest.
Shows verified real-time information and basic parking information separately.
But the first public release I wanted to build was not an app explaining the limits of nationwide data. I wanted to first build an app I actually used, whose sources I could keep checking, and whose screen I could verify against reality.
So I returned to the Han River.
The Han River is narrow. The number of parks is limited, and the app can handle the context needed before and after a visit: parking, facilities, events, congestion, weather, and notices. Most importantly, it is a place I visit often, so I could immediately check whether numbers and screens led to actual choices.
Should I go to Yeouido or Banpo? Should I bring the car or use public transit? Can I leave after seeing the parking widget? Should I switch parks after seeing event or congestion signals?
These choices became clearer when treating the Han River deeply instead of covering the country thinly.
It was a place I could verify directly
Another reason for focusing on the Han River was direct verification. If a number looked strange, I could compare it with my own experience. If screen copy was vague, I could read it again from the mindset I have before moving. Having the maker and first user in the same situation was more valuable than expected.
For example, it is hard to judge from documents alone whether the word “crowded” is too strong, whether a parking lot marked “available” is actually inconvenient because of an entrance line, or whether the widget’s updated time is noticeable enough. For a place I visit directly, these small mismatches appear faster.
The Han River is narrow, but its usage is diverse enough. People go by car, by subway, with children, for night walks, for events, or simply to sit on a mat. Even without national expansion, it is complex enough to learn what the app should say and what it should hide.
After thinking this through, the word “small” looked different. The place is small, but user situations are deep enough. Because I visit often, I can notice small misalignments earlier.
Deciding what not to do made the app clearer
I did not permanently abandon the nationwide outing-app idea. I decided not to do it now.
While building an app, it is easy to say, “This can expand later.” But that sentence must not blur today’s quality. In the first version of Hangangjari, what mattered more than future expansion was whether users could trust the current screen and move based on it.
So the first public scope became Hangang parks. I chose to connect parking, congestion, events, facilities, notices, widgets, and notifications properly inside that narrow area.
That made the app description clearer.
Hangangjari’s goal is not to know every outing destination. It is to gather the information that can be checked now before going to the Han River and while being there.
An app is not better because it sounds bigger. Once I removed claims I would not make, the remaining words became more trustworthy.
Features removed from the first public release
When reducing scope, it helped to separate “someday” from “not now.”
| Not done now | Reason |
|---|---|
| Real-time parking for every park nationwide | It was hard to speak reliably about real-time remaining spaces. |
| Automatic park-to-parking-lot matching | A nearby lot is not guaranteed to be a good lot for actual visitors. |
| Complex screens explaining regional quality differences | For the first release, trust inside the Han River area came first. |
| Renaming the brand into a broad outing app | The words became larger than the scope I could responsibly own. |
Writing down discarded ideas also reduced attachment to them. If I expand later, it is clearer what needs to be verified first.
Expansion has to answer the same questions
Nationwide expansion is not closed forever. But the questions held in the first release need to remain later too.
- Can this data be called real-time?
- Can I explain its source and updated time?
- Will users misunderstand it when actually moving?
- Can the app honestly show what it does not know?
Expansion should begin with regions where these questions can be answered. Building something trustworthy in even one region came before changing the name to something larger. Focusing on the Han River was therefore not just narrowing down; it was defining the promise.
The decision to stay with the Han River also defined what the app could say. Show only what has been checked instead of claiming to know many places. That attitude set Hangangjari’s size. The narrow first-release scope was not a stopgap; it was the size of the promise the app could keep.
Share
No comments yet. You can leave the first one.
Pending review