Ship-a-ton 2026: A Break App That Respects Focus

In Build Log #1, we shared how we went from more than ten product ideas to one specific problem we wanted to explore: helping people who spend long periods focused, sitting, or looking at a screen find natural moments to step away from what they are doing.

Once we had defined the problem, we also had several assumptions that, without realizing it, were starting to look a lot like solutions. We imagined very short breaks. We thought reminders would be at the center of the experience. We liked the idea of a virtual companion that could make breaks feel a little more engaging. And we assumed some of our early users were probably already tired of alarms, Pomodoro timers, and similar tools.

The next step was to stop discussing these ideas among ourselves and get closer to reality. We designed a survey, looked more deeply at existing products, and started asking what really happens when someone knows that stepping away for a moment might help, but still does not do it.

Turning our first product assumptions into questions we could actually investigate.

What We Thought

Our initial hypothetical story was pretty simple:

Someone gets focused on work → loses track of time → gets a reminder → takes a short break → gets a small "reward".

We also assumed that:

• breaks would probably need to be very short, somewhere between 30 and 120 seconds;
• forgetting to take a break could be one of the main problems;
• many people had probably already tried reminder tools and stopped using them;
• a companion or pet could make the experience more motivating;
• if breaks were short and easy, that might be enough to make people actually take them.

None of these ideas were unreasonable, but they were still hypotheses.

The surveys we ran with potential users were important because they helped us make decisions based on actual evidence. That was also when our original story stopped looking so simple.

What We Found

1. Reminders and Interruptions

People did talk about losing track of time or simply forgetting to take breaks, but another tension came up again and again: they did not want to be interrupted when they were deeply focused.

Someone can know that taking a break might be a good idea and still ignore the reminder because it arrived while they were finishing a task, presenting in a meeting, solving a problem, writing something, or simply because they did not want to stop at that moment.

That helped us recognize something important: a reminder can make sense at certain times of the day and still feel annoying when it arrives at the wrong moment. We moved from asking "How often should we remind someone to take a break?" to asking: "When and how could a suggestion actually be useful?"

2. “Microbreaks” Were Too Limited

At first, we really liked the idea of breaks lasting between 30 and 120 seconds. From a friction point of view, it made sense: if a break is very short, it should be easier to accept. However, the survey did not point to one clear duration. Some people preferred breaks that lasted a few minutes. Others basically told us: “It depends.”

With that in mind, we stopped thinking about duration as a fixed product rule. One minute looking away from the screen is not the same as a five-minute walk, and the amount of time someone has available is not the same throughout the day.

We started seeing break duration as something our product could suggest and the user could change.

3. Using — or Not Even Knowing About — Break Apps

Another early assumption was that a large part of our audience had probably already tried dedicated break apps and stopped using them, but the survey showed a more mixed reality. Some people had used alarms, Pomodoro timers, smartwatches, videos, or workplace reminders. Almost half had never searched for or used a dedicated break app.

That made us think about two different product problems: If someone tried five apps and abandoned them, we need to understand why they stopped using them, but if someone has never looked for a tool like this, the question is different: Does the problem feel important enough for that person to want a product at all?

That led us to stop assuming that people are already tired of existing break apps, because our research simply did not support that claim strongly enough.

4. More Reminders?

One of the clearest signals from the survey was notification fatigue. We started to notice a contradiction: we were trying to solve a wellbeing problem using one of the things people already experience as an interruption.

Notification design stopped feeling like a technical detail and started becoming a central part of the product idea. Instead of only thinking about inviting people to take a break, we started exploring responses like:

• Now
• Later
• Not now

“Later” matters because sometimes someone does want to take a break, but the timing is simply wrong. “Not now” matters because the app should be able to accept a real no, without creating consequences such as lost progress, guilt, or emotional pressure from a sad companion.

Benchmarking as Support for What We Found in the Survey

During the early idea exploration, we had already done a light competitive benchmark. We looked at what solutions existed, and how crowded the market seemed. Then, through the survey, we tested our assumptions against people’s actual experiences. As we thought about how to validate what we were seeing — including ideas like WhatsApp bots — we decided to do a much deeper benchmark.

That second round helped us validate and support several of the frustrations we had found in the survey. This time, we looked at some of the strongest competitors in more detail: flows, reminders, snooze options, notification tone, progression systems, paywalls, user reviews, and how much attention each product asked from the user.

The same tensions we heard in our research also appeared in the market: People wanted support, but not pressure, personalization, but not too much setup, motivation, but not guilt, reminders, but not constant interruption... We moved from trying to differentiate mainly through visuals and personalization to asking how we could combine low friction, good timing, and emotional personality without turning wellbeing into another obligation.

What We Changed

Our initial idea was already starting to grow into something more meaningful. One of our first concepts was close to: “A creature that needs you to move.” It sounded memorable, and visually it had potential. But it also created several difficult questions: What happens to the creature if you cannot take the break? Does it get sad? Do you lose progress? Could a wellbeing app end up becoming just another responsibility?

Thanks to what we learned, we became clearer about what we did not want. The companion stopped being mainly a motivation mechanism and started becoming more of an emotional layer and a source of companionship throughout the experience: it would not need to be cared for, it would not depend on whether the user takes a break or not, it would simply be there if the user wanted to pause. That also helped us define some early product principles:

• interrupt less, instead of simply reminding more;
• ask before telling;
• “not now” is a valid answer;
• suggest before forcing people to configure everything;
• make it easy to start a break quickly;
• keep screen time low;
• make progress feel like progress, but never turn lack of progress into punishment.

What We Still Don’t Know

Our solution is taking shape, but we still need to move forward before we can call it even an initial functional MVP. More important questions kept coming up:

• Should our product stay almost invisible, or have a stronger visual presence?
• Should the app immediately suggest a break, or first ask what would be useful?
• How much personalization adds value before it becomes another setup task?
• Should the user choose the duration, or should the system suggest it?
• How much personality can the companion have before the product starts to feel childish?
• Can we make notifications useful enough that people do not end up turning them off?

And most importantly:

How much of this can we build well enough and still make the Shipaton deadline?

What We’re Testing Next

That last question led us to our next design exercise. Instead of trying to immediately arrive at one polished solution, we decided to explore very different versions of the same product. One direction was extremely simple: fewer decisions, fewer visual elements, and an almost invisible experience. The other had a much stronger presence: pixel art, a more visible companion, different break types, and more options depending on the context.

Both solved important parts of the problem, and both came with clear risks. So the next question became: Do we choose simplicity or personality?

Stay tuned to find out in our next Build Log.