The Hangang Parking Widget I Built After Buying a Car

In June 2026, I published the iPhone app Hangangjari on the App Store.

It is a free app with no login, ads, or in-app purchases. It was less a product designed around a business model and more a project to reduce a small inconvenience I kept running into.

I did not set out to build a large service. The beginning was smaller. I often went to the Han River, especially Yeouido Hangang Park. I used to go almost entirely by public transit. I would get off the subway, walk to the park, buy something at a convenience store, and find a spot.

Back then, going to the Han River was simple. If the weather was fine and the timing worked, I just went. There was not much to check on the way. For me, the Han River was not a destination to evaluate before leaving. It was a familiar place where I arrived and spent time.

After buying a car, the number of things I had to check before going to the Han River suddenly grew.

After “Should we go to the Han River?” came another set of questions.

Which parking lot should I enter?
Are there spaces right now?
If the entrance line is long, where should I reroute?
What happens if the lot is already full when I arrive?

Before leaving, I often opened the integrated Hangang parking portal to check remaining spaces. Finding and opening that web page every time was more annoying than I expected. The worse moment was leaving without checking. When cars were lined up at the parking-lot entrance, turning around to another lot became tiring fast.

The first thought was simple.

I wish I could see this directly in an app or widget.

That question became the starting point for Hangangjari. If I could quickly check remaining spaces right before going to the Han River, the hesitation before leaving home would shrink.

The first goal was to save ten seconds before departure.

At first, that was enough. Hangangjari did not begin as a large map service or a platform for every park. It began as a way to glance at the phone before picking up the car key and answer, “Which parking lot should I choose today so I wander less?”

I focused only on parking at first

Early parking-focused home screen

Looking back at the earliest notes, Hangangjari had a very narrow scope. Before going to Hangang Park, I wanted to check parking conditions quickly and, if needed, move straight into navigation. I especially wanted to solve the Yeouido Hangang Park case first: choose where to park with one widget glance before leaving.

The success criterion was also simple. If I used it myself and opened the parking portal less often when going to the Han River, it worked.

So the first build quickly added remaining parking spaces, congestion status, parking-lot detail, favorites, navigation handoff, and widgets. In mid-May 2026, I separately wrote down how far to take a Hangang-park-centered parking app.

Starting small turned out to be a good decision. It was a problem I actually had, and the usage scene was clear. I could also tell quickly whether the direction was wrong. If I still opened the web page before going to the Han River, the app had failed.

At this point, Hangangjari was still close to a “Hangang Park parking widget.” But because I was building it for myself, another problem appeared soon. Deciding to go to the Han River did not end with one parking lot.

The four questions the first version had to answer

The early version was meant to answer four questions.

Question	What the screen should show
Can I take the car?	Remaining parking spaces and status
Which parking lot is better?	Recommended candidates and navigation handoff
Can I trust this information?	Updated time and status labels
Do I have to open the app every time?	Favorites and widgets

This table helped later when cutting features. Even if a feature looked useful, if it did not answer one of these four questions, I postponed it for the first version.

Personal projects lose direction quickly when you start adding everything you want. Hangangjari stayed focused from the beginning on choosing a parking lot before going to the Han River, and that is why it reached a usable state.

Once the question narrowed, the first screen naturally became lighter. I thought first of someone checking the phone briefly right before leaving, not someone browsing the app for a long time.

Making the choice right before leaving

I used the scene of looking at my phone before leaving home on a weekend afternoon as the baseline. I quickly choose whether Yeouido Parking Lot 1 has space, whether I should go to Lot 2, or whether it is better to switch to Banpo or Mangwon.

If I am already in the elevator or sitting in the car, I do not have time to move through several app screens. What I need then is a short judgment: “Where should I go now to wander less?”

That is why I removed several things from the early screen: park marketing copy, long explanations, decorative cards, and detailed information for every parking lot.

Those things may matter to someone opening the app for the first time, but in the moment I wanted to use it, they got in the way. Hangangjari needed to feel less like a tourist guide and more like a tool for choosing where to go right before departure.

It had to work before opening the app

Parking information can be too late if it appears only after opening the app. The decision about whether to go to the Han River, and whether to bring the car, usually happens before leaving home. That made the widget outside the app as important as the home screen inside it.

The early widget had a simple goal: choose one favorite park and quickly see the remaining spaces and status. More precisely, it was about getting a sense of whether I could bring the car today without opening the app.

Thinking about the widget first simplified the data and the screen. The widget did not need every parking lot. Recommended lots, updated time, and status labels mattered more because they fed directly into the decision.

The app screen came next. The natural flow was to get the rough answer from the widget, then open the app only when I needed a closer comparison.

A small problem carried the project to the end

If I had started with a large name like “a Seoul outing platform,” the app would have become scattered quickly. The more there is to show, the heavier the screen, data, and explanation become. The opposite goal, “make me open fewer web pages when I go to the Han River,” was much more realistic.

Because the problem was small, deciding what to build was easier. When something was unclear, I returned to the real moment of use. Does this help within ten seconds before going to the Han River? Is it clear in a widget? Does it avoid recommending a parking lot that is nearly full? Features that did not meet that standard waited.

The first version of Hangangjari put a small repeated checking behavior at the center of the app. Because that behavior happened often enough, it was worth turning into an app.

Features I left out of the first version

There were also many things I intentionally did not build: signup, server-synced favorites, community features, reviews, user-submitted parking reports, payments, ads, and complex personalization. They may look useful, but they were not necessary for solving the first problem.

I especially did not add login. A frequently visited park or parking lot could be stored on the device, and account creation was too heavy for a pre-departure checking tool. An app meant to save ten seconds before going to the Han River would lose its direction if the first launch asked for an email address.

I treated favorites simply as well. They did not need server sync. It was enough to quickly reopen the parks I often checked on this device. Small decisions like that shape the character of an app. Hangangjari should not be an app that holds the user for a long time. It should open quickly and close quickly at the moment it is needed.

The first screen kept only decision clues

The same rule shaped the home screen. The first priority was not introducing the entire Han River beautifully, but helping someone decide whether it was worth going right now.

So parking-lot names, remaining spaces, status, and updated time came first. A person seeing the screen should be able to decide, “This one looks better,” or “Now seems uncertain.” Status came before pretty description. The next action came before long guidance.

Even after adding the general mode later, this standard stayed. As information grew to include park congestion, events, facilities, and notices, the first question stayed the same: does this directly help someone who is about to go to the Han River or who is already there looking for something? Building Hangangjari was a repeated check against that question.

Looking back, the best decision in the first version was not adding many features. It was capturing the uncomfortable moment accurately. Because I remembered wandering near a parking-lot entrance, the screen priorities and the reason for the widget stayed stable.

Rather than expanding the app to look large from the beginning, I first focused on reducing a repeated check in my own routine. Because the use scene was clear, the widget and first screen priorities became clear. Later, even after adding the general mode, the direction stayed the same: help people find the facilities and access points they need inside the Han River area.