Fix Stories: The Day I Stopped Calling Work Rush Finished

A solo developer’s post-launch reflection on mobile design, readable pressure, and redefining when a game is finished

A game can function exactly as intended and still not be ready for the people expected to play it. In this Fix Stories submission, Jaehoon Lee of Songi Store reflects on the moment he stopped treating “everything works” as the same thing as “the game is finished.”

Work Rush is a free Android typing survival game about keeping up with an office workload that becomes increasingly difficult to control. Its central idea was simple, but bringing that idea to a real phone revealed problems that were almost invisible on a desktop screen.

---

Want more stories from game developers?

Get more developer stories, interviews, reviews, indie coverage, and gaming news from Fix Gaming Channel.

There was a version of Work Rush that I was ready to call finished.

The menu worked. A run could begin. Office memos arrived in a queue, the player typed them away, the score rose, and the game could end with a result screen. In a desktop browser, it had all the visible signs of a completed game: systems, effects, progression, and no obvious broken button.

Then I started treating it like a game that would actually be played on a phone.

Work Rush is a small survival game built around office work piling up. Memos arrive faster and faster; the player clears them with the phone’s software keyboard before the board overflows. The original premise was intentionally simple. I liked the idea that a familiar frustration, a task list growing faster than it can be cleared, could become a readable game loop.

What I underestimated was how easily a readable loop can become an unreadable mobile game.

The false comfort of a complete-looking screen

On desktop, I had been asking the wrong question. I asked whether the interface fit together. I did not ask whether a player could understand it while under pressure.

A mobile game does not give every element equal attention. The player is reading a target, watching the next memo, deciding whether to use a recovery tool, and typing at the same time. Once the phone keyboard is open, the remaining space is not just smaller; it is more expensive. Every animation, toast, badge, and panel competes with the one thing the player needs to notice next.

The first practical change was not a new mechanic. It was a testing habit.

I began running short sessions with the software keyboard open and writing down every moment where I hesitated. Not every hesitation was bad. Some belonged to the game. If the board is filling up, the player should feel pressure. But there is an important difference between “I have to make a decision” and “I cannot tell what the game wants me to look at.”

That distinction changed the layout. It changed when feedback could appear. It changed how much visual celebration a cleared memo deserved. A flashy confirmation can feel rewarding in a still screenshot, but it is not worth much if it hides the next threat for half a second.

The rule I settled on was simple: during a run, the player should always be able to answer three questions without searching the screen.

• What should I type now?
• What is about to make this run harder?
• What do I still have available to recover?

If the interface could not answer those questions quickly, the game was not difficult in an interesting way. It was merely asking the player to fight the interface.

Making a slow game tense without making a fast game unfair

Pacing was the next lesson.

Early versions of Work Rush had two opposite problems. If the opening was too calm, it felt like an office-themed typing exercise. If boss instructions, disruptive memos, and other special events arrived too close together, the run became hard for reasons that were impossible to read.

Both versions were technically playable. Neither one had a useful rhythm.

The solution was not to remove pressure. The game needs pressure; it is the entire reason the queue exists. The work was in making that pressure arrive through a pattern a new player could learn.

The opening minute now has a specific job. It has to show the basic loop, establish the pace, and let the player recognize the queue before it asks them to recover from trouble. Later, the game can accelerate and introduce more demanding situations because the player has already learned how ordinary work behaves.

That sounds like a small design adjustment, but it changed how I judged failure. A loss should still feel fair when it is sudden. The player should be able to say, “I let the board get away from me,” or “I used the wrong tool too early.” If the only explanation is that several unrelated things appeared at once, then the game has hidden the decision that was supposed to matter.

For a solo developer, this was a useful correction. It is easy to look at a growing list of features and assume more variety automatically creates more depth. In a short mobile session, variety only becomes depth when the player can recognize why each new thing matters.

A recovery tool has to answer a problem the player can see

That led to a second mistake: I had initially thought about support tools mostly as rewards.

Work Rush has ways to interrupt or soften a bad situation: clearing part of the queue, slowing the pace, pausing time, creating extra capacity, or handing selected normal work to an assistant. These sound good in a feature list. In a real run, they only become meaningful when they answer a danger the player has already noticed.

A cleanup option is useful when the board is visibly crowded. A pause matters when the player needs a moment to read again. Extra capacity matters when the player understands that one more incoming memo will end the shift.

That sounds obvious, but it gave me a much better test than “Is this upgrade strong enough?” The better question was, “Can a player see the situation this tool is meant to solve?”

If the answer was no, the tool was not strategy. It was just inventory.

The last ten seconds matter as much as the first ten

I also had to rethink the end of a run.

Short mobile games are often judged at the moment of failure. A player may only spend a few minutes in a session, so a confusing result screen or an abrupt interruption can erase the clarity built during the run itself.

I wanted a lost shift to give the player a useful next thought: what went wrong, what they earned, and what they might do differently next time. A revive needed to feel like a deliberate chance to recover, not a screen that simply appeared because the run had ended. Rankings needed to reflect completed attempts rather than rewarding a half-finished situation.

None of that is as immediately visible as a new enemy or a new skill. But it changes whether a player restarts because they are curious, or closes the app because the game has not explained itself.

What “finished” means now

The premise of Work Rush is still the same. It is a game about typing through an increasingly impossible office day. The part that changed was my definition of polish.

I used to think a game was finished when all its parts were present and working. Now I think it is closer to finished when a person on a real phone can see the pressure, understand their choices, make a mistake, and still feel that another run is worth trying.

That lesson is less glamorous than a new feature announcement, but it has shaped every later change I make. Mobile constraints are not details to hide after the design is complete. They are part of the design itself.

Work Rush

Genre: Typing Survival Game

Developer / Publisher: Jaehoon Lee / Songi Store

Platform: Android

Availability: Free via Google Play

Related Reading

Fix Stories — Real Stories From Game Developers and Creators

Fix Stories: I Always Wanted to Run a Band, So I Built One

Fix Stories: Where Spears & Spirits Came From

---