Why Hangangjari Chose the Han River Over Nationwide Coverage

While building Hangangjari, I once wanted to give it a larger name.

If the first feature is parking checks, the next imagination comes naturally. Would the app look larger if it had a name broader than Hangangjari? Mine did.

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 research did not support my initial expectation.

It was possible to gather park and parking-lot lists nationally. But to decide whether to take the car right now, users also 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, and that varied by region.

With public data alone, it was not realistic to speak reliably about real-time parking for every park in the country.

A broader name made the app look bigger, but the actual service level still varied by region. I set the first release to a scope where I could directly verify sources and updated times for information needed before and during a Han River visit.

Three Problems Revealed by 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.

Real-time availability was the first problem. 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.

Matching was the second problem. 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.

Explanation responsibility was the third problem. 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.

A Verifiable Scope Over a Broad Name

When I wrote an App Store description around more locations, the copy became broader than the features I could provide.

Shows real-time parking availability for every park nationwide.

That was a larger promise than I could keep. The actual distinction I could show was closer to the following.

Shows verified real-time information and basic parking information separately.

For the first public release, I chose places I used regularly and whose sources and screen copy I could keep checking.

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 concrete when parking, events, facilities, and access points for Hangang parks were checked together.

A Place Open to Direct Verification

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.

The Scope Chosen for the First Release

The nationwide outing app was excluded from the first public release. The first public scope became Hangang parks. I chose to connect parking, congestion, events, facilities, notices, widgets, and notifications properly inside that narrow area.

Once I excluded nationwide coverage, the app description matched what the first release provided.

Hangangjari’s goal is to gather the information that can be checked before going to the Han River and while being there.

Features Left Out of the First 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.

Questions to Answer Before Expanding

Adding another region would require answering the same verification questions used for the first release.

• 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?

Only a region that can answer these questions becomes the next candidate for expansion.