I positioned my Android app around the wrong user moment — here’s what I changed

Jaehoon Lee — Mon, 10 Aug 2026 03:12:06 +0000

I recently noticed that the screenshots and short-form posts for my Android app were explaining a different product from the one I had actually built.

The app's real loop is simple:

The user has already decided on one place.
They search for that real place.
The app shows a playful daily “fit between me and this place” score and a short reading.

It is not a place recommender, route planner, or two-location comparison tool. But my early store assets kept showing two places side by side because comparison looked more dramatic in a screenshot.

That decision made the product harder to understand.

The positioning bug

I had treated marketing assets as a feature inventory. Search, scores, history, and multiple screens all appeared at once.

The result was technically accurate in pieces, but wrong as a story. A viewer could reasonably think:

“Is this choosing a destination for me?”
“Do I need to compare two cafés?”
“Is this a navigation app with a score?”

None of those matched the first useful moment in the app.

The correction

I rewrote the visual sequence around one sentence:

I already chose this place. How does it feel for me today?

That changed the order of every asset:

Start with one recognizable place.
Show the user searching that exact place.
Show the actual result screen long enough to read it.
Explain the score as a light daily reflection, not a prediction.
End with one action: search the place you already plan to visit.

I also removed decorative score badges and fake comparison cards from promotional visuals. If a screen did not exist in the app, it no longer appeared in the ad.

Four checks I now use for store screenshots

1. Test the first screenshot at thumbnail size

If the main sentence cannot be understood before opening the listing, the screenshot is too busy.

2. Describe the user's moment, not the feature

“Search places” is a feature. “Check today’s feeling with the place you already chose” describes why the user opens the app.

3. Keep one noun consistent

Switching between place luck, recommendation, compatibility, and comparison made the app sound like four products. I now keep the core phrase consistent: today's personal place fortune.

4. Do not let a more dramatic demo replace the real flow

Two scores moving against each other looked dynamic in a short video, but it trained viewers to expect a comparison product. The real result screen is less theatrical and more honest.

What I am measuring next

The immediate goal is not downloads at any cost. I want to learn whether a store visitor can answer these three questions without extra explanation:

Is this for one place or two?
Do I use it before or after choosing the place?
Is it entertainment or practical navigation advice?

If those answers are unclear, more traffic will only create more confused visitors.

Disclosure: I built Unse Nadri, the Android app discussed here. It is free with ads and intended only as a light entertainment/reflection experience, not as a reliable prediction or advice tool.

If you want to inspect the revised one-place flow, it is on Google Play:

https://play.google.com/store/apps/details?id=com.unsenadri.app&hl=en&gl=US&utm_source=devto&utm_medium=ux_case_study&utm_campaign=single_place_positioning_20260810

I would especially value feedback on whether “today's personal place fortune” makes the core idea understandable in English.

How I prevent unsupported places from looking 'live' in a Capacitor travel app

Jaehoon Lee — Wed, 29 Jul 2026 16:07:18 +0000

I ran into a product bug that was easy to miss because the UI looked polished: places outside the supported live feed could still carry a numeric crowd value from a catalog or fallback path.

The number was valid JavaScript. It was not valid live data.

That distinction matters in a travel app. A user may change plans based on a badge that says "live", so a plausible-looking fallback is worse than an honest empty state.

This is how I tightened the boundary in Gap-trip, an Android app built with JavaScript, Capacitor, Firebase, and public tourism data.

1. Make provenance part of the type check

Checking only whether a value is numeric was not enough. I added one predicate that requires both a number and evidence that it came from the supported live pipeline.

function isRealtimeCrowdPlace(place = {}) {
  return Number.isFinite(place.crowd) && (
    place.crowdDataAvailable === true
    || place.source === "서울 실시간 도시데이터"
    || place.forecastSource === "seoul-citydata"
    || String(place.id || "").startsWith("seoul-citydata-")
  );
}

The important part is not the exact source names. It is that "has a number" and "is live" are different facts.

2. Normalize unsupported values once

After the predicate runs, unsupported crowd fields are removed before the object reaches the rest of the UI. Weather and air-quality data can still remain available.

const hasRealtimeCrowd = isRealtimeCrowdPlace(place);

return {
  ...place,
  crowd: hasRealtimeCrowd ? place.crowd : null,
  usualCrowd: hasRealtimeCrowd ? place.usualCrowd : null,
  forecast: hasRealtimeCrowd ? place.forecast : [],
  forecastSource: hasRealtimeCrowd ? "seoul-citydata" : "none",
  crowdDataAvailable: hasRealtimeCrowd,
  crowdDataSource: hasRealtimeCrowd ? "realtime" : "none",
};

Doing this at one boundary is safer than asking every card, map marker, detail panel, and share image to remember the same rule.

3. Reuse the same predicate in filters

A "show only places with live crowd data" toggle must use the same definition as the badge renderer. Otherwise the filter and the card can disagree.

.filter((place) => !state.crowdOnly || isRealtimeCrowdPlace(place))

This sounds small, but duplicate definitions of "live" were exactly the kind of drift I wanted to avoid.

4. Degrade the score, not the truth

When crowd data is unavailable, the place does not disappear. The recommendation can still use available conditions such as weather, air quality, travel time, transit access, and nearby facilities. The UI says that the score used the other available conditions instead of fabricating a crowd signal.

This gives up some visual consistency: fewer cards have colorful crowd badges. I think that is the right trade. An empty field is recoverable. Misplaced trust is not.

5. Reject a partially broken batch

A successful HTTP response can still contain too little usable coverage. The app therefore checks whether the live set is healthy before treating the batch as live. The current minimum is 30 supported places.

const MIN_HEALTHY_REALTIME_CROWD_PLACES = 30;

function hasHealthyRealtimeCrowdSet(places = []) {
  return Array.isArray(places)
    && places.filter(isRealtimeCrowdPlace).length >= MIN_HEALTHY_REALTIME_CROWD_PLACES;
}

The backend also times out upstream calls, caches valid results briefly, and returns an explicit unavailable response when the live batch fails. A 200-shaped payload is not automatically a healthy product state.

What I test now

The release scripts include crowd resilience, nearby coverage, soak, and failover checks. The cases I care about are:

a valid live value with supported provenance;
a numeric fallback with no live provenance;
a partial batch below the coverage threshold;
an upstream timeout;
a place with weather data but no crowd data;
the live-only filter after a failed refresh.

The broader lesson for me was simple: availability is a product claim, not just a data shape. If the UI says "live", the code should be able to prove why.

Gap-trip currently applies this rule only where supported public live data is available; it does not claim live crowd coverage for every place. If you want to inspect the behavior:

I would be interested in how other teams represent provenance when multiple public-data sources feed the same UI.

DEV Community: Jaehoon Lee