The Code Took an Evening. One Decision Took More Thought.
YouTube keeps resetting my playback speed.
So I built Paace, a small Chrome extension that puts it back.
The fix was easy. One decision took more thought: what happens when you change the speed for a single video.
The easy version
The easy version saves every change as your new preference. Slow down one tutorial and everything after it plays slow.
Almost every product ships the easy version, because it falls out of the code. You already have a stored value. The user just set a value. Overwrite it, done. One state, no edge cases, and the demo works perfectly.
It's only wrong in real life. The user didn't declare a new preference. They made an exception, and the software promoted it to policy without asking.
What you did versus what you meant
In Paace, a one-off change stays one-off. Your saved speed only changes when you choose to save it.
That's the whole decision: the gap between what you did and what you meant. Slowing a tutorial to 1x doesn't mean you've become a 1x person. It means this video, right now, needs 1x. The preference and the exception are different things, and collapsing them is how software slowly stops feeling like yours.
You've met the collapsed version everywhere. Watch one video outside your taste and the recommendation feed rebuilds itself around a moment of curiosity. Buy one gift and the ads decide it's your identity. Mute one meeting notification and something, somewhere, decides you don't want notifications. Every action gets treated as a declaration, because inferring intent is hard and overwriting a variable is easy. It's the same shortcut that produces slop: shipping the first version that works instead of the version that's right.
Getting it right costs something. Paace needs two kinds of state instead of one, a session value and a saved value, and a deliberate action to move one into the other. Slightly more code, slightly more design. In exchange, the tool never surprises you, which for a utility is the entire product.
Small tools expose big decisions
This is the second small tool I've shipped this month, after Waalk, and I keep noticing the same thing: the smaller the product, the more visible the design decisions become. A big app can bury a lazy default under forty features. A speed controller is one decision wearing a UI, the way the Cybercab is one button wearing a car.
That makes utilities the best design education there is. You can't hide behind scope. Every choice, what persists, what resets, what asks permission, is the product. It's the same discipline that operational software teaches: the person on hour ten thousand notices exactly one thing, whether the tool respects their intent or fights it.
And the barrier to learning this way is gone. An evening of building, no dev team required, and you get to make the decision instead of writing an opinion about it.
Where it is
Paace is on the Chrome Web Store.
It puts your speed back when YouTube resets it, and it never mistakes an exception for a preference.
The fix was easy. The respect took design.
---
