I set out to fix a serious synchronization problem in Accumoo. Working through it made me question the feature I was trying to fix.

Now I’m reconsidering some of Accumoo’s core features, and I’m a little anxious about it.

An Event in Accumoo is something a user tracks, such as walking or reading. Its progress, history and statistics need to make sense across the user’s devices. Pause started with a straightforward intention: let users take a break without hurting their statistics. Life happens. Watching your statistics suffer because you needed a break can feel like punishment. Building with a little empathy seemed reasonable.

A simpler product could be a better product. But changing a product people already use is risky. I have about 140 users, with a handful being paying customers. Some may be disappointed by the changes I’m considering. Some may leave or leave bad reviews. I’m concerned about what this could mean for an app that’s still trying to find its audience.

This question keeps haunting me:

Will Accumoo, and all the hard work I’ve put into it, turn to ashes before it’s even had a chance to catch fire?

I don’t have enough user feedback to know whether I’m making the right decision. I’ve added functionality I thought users would want. Now I’m considering changes because I think they’ll make Accumoo better. I’m still making assumptions.

I look at other successful apps for ideas, but their success doesn’t guarantee a similar approach will work for Accumoo and my users. That’s the catch-22: I want to improve Accumoo without simply replacing one set of assumptions with another.

What does taking a “break” actually mean?

If someone pauses an Event, how should this affect their history and statistics? How should progress recorded on another device be handled if it hasn’t received the pause yet? And when the user resumes, what should the app do with the history—or the lack of it—in between?

How Pause works determines what history needs to record, and history determines what statistics are presented to the user. These decisions are inextricably linked.

The intent is clear. The details are where I keep getting stuck.

Accumoo’s local-first architecture lets users record progress without a connection. An iPhone and an iPad can temporarily disagree about whether an Event is paused. Synchronization has to reconcile their changes, but first I need to decide how Pause should affect progress and statistics across devices.

Where the implementation made me reconsider the product

Resuming an Event involves more than clearing a paused flag. The app has to advance its tracking periods —the hourly, daily, weekly or other intervals used to measure progress—and record how the break affects its history.

An hourly Event paused for months can leave thousands of periods to account for. A single tap on Resume can trigger a lot of work. This work has to preserve existing progress and synchronize correctly with devices that may not have received the same changes yet.

Testing Pause and Resume across devices exposed failures that needed fixing. But working through them made me question whether the feature justified its complexity—especially when the resulting statistics could be confusing even to me. Was I making the code more complicated to support a feature that needed rethinking?

I want the right fix. I don’t want a hack that will cause a maintenance nightmare later.

Part of finding the right fix is deciding whether the feature itself needs to change.

Finding another way forward

I started by asking how to make the existing feature work reliably. Stepping back revealed another question: was this the best version of the feature for users in the first place?

This meant rethinking the feature rather than the code.

Taking a break and seeing meaningful progress are still worth supporting. But I don’t have to keep the current feature design to support these needs. Redesigning the feature gives me another way to solve the underlying problem—and an opportunity to simplify the code supporting it.

Adding more code to preserve the current behavior means more interactions to test and more complexity to understand the next time I need to make a change. I have to maintain all of this long after the immediate bug is fixed. The bugs still need fixing, and existing progress and changes waiting to synchronize still need protection. I’m questioning how much additional complexity the feature really needs.

Sometimes the best code fix comes in the form of a better feature. I’m pursuing a redesign that I hope users will find clearer and more useful, with rules that are simpler to implement reliably. This could make Accumoo easier to maintain and give me more room to change direction later.

Having another way forward doesn’t remove the risk. I can test whether the code behaves as intended. Finding out whether I’ve made a better feature means putting it in front of users—and accepting that I might be wrong. This is the uncomfortable part of moving forward without enough feedback to know how they’ll respond.

The feature redesign is part of the engineering solution. In the next post, I’ll share the changes I’m considering and why.