You check the app. It says the bus arrives in eight minutes.
You wait. Nothing comes.
The number was not random. The schedule was real. The UI looked confident. And you still got stranded, because the product answered “when” when you needed “will this bus actually leave?”
When the data model cannot answer that question, a “correct” UI still feels dishonest.
Why this keeps happening
Founders and CTOs who own design by default often ship the data they have, not the question users are asking.
That creates rework disguised as polish: better typography on a weak answer, clearer empty states that still do not help, and support threads that sound like edge cases but are core journeys.
Edge cases are where trust dies first, especially when the happy path looks fine in demos.
The terminus problem in SePoso
SePoso is a mobile-first Athens bus and trolley app that puts a daily commuter’s arrival on the home screen without repeating the official line-first search.
Near starting stops, riders hit a different question than “how many minutes?”
They were asking: will this bus actually start?
Live data often is not available until after departure.
A scheduled time that never ran left people waiting far longer than expected, with high frustration and no useful honesty from the product.
Experienced riders already had a workaround: check the opposite direction approaching the terminus.
If that vehicle is coming back, service is probably alive and their direction may leave soon.
That was not power-user trivia.
It was local product knowledge the UI ignored.
The decision
We encoded the workaround into delayed-start behavior instead of pretending the live feed was complete.
When a departure looked delayed:
- Keep the signal visible instead of silently wrong
- Surface inferred timing when opposite-direction data helps
- Prefer honest uncertainty over a false sense of precision
The point was not clever math.
It was answering the real job near the terminus: is service happening, or am I standing here for nothing?
What to try next time
When users complain that “the app lied,” do not only audit the number.
Ask:
- What decision were they trying to make in that moment?
- What data do we actually have for that decision?
- What workaround do experienced users already use?
- Can we productize the workaround instead of hiding the gap?
Honesty is alignment between the user’s question and the product’s answer, including when the answer is incomplete. Tone of voice cannot cover that gap.
If this sounds familiar
If your product looks accurate in demos and still burns trust in edge journeys, that is a product ownership problem: someone has to own the question, not just the feed.
If this kind of product judgment is what you’re trying to install on your team, we’re happy to talk. And if you know someone else who should be in that conversation, we’d love an intro.
