As developers, we spend our days making high-stakes decisions: architecture patterns, library choices, and debugging logic. But ironically, when it comes to the small things—like where to eat lunch or which task to tackle first in a long backlog—I often find myself stuck in decision paralysis.
I looked for a simple tool to offload these trivial choices to fate, but most of what I found was cluttered with intrusive ads or required a cumbersome signup process. I wanted something clean, fast, and satisfying to use. That is why I built SpinDecide.
The "Why" Behind the Project
The goal was to create a tool that felt tactile. There is a psychological difference between clicking a "Randomize" button and watching a wheel spin. The anticipation of the wheel slowing down makes the result feel more earned, even if the underlying logic is just a math function. I wanted to provide a utility that students could use for classroom participation, gamers could use for prize giveaways, and teams could use to break ties in a neutral way.
The Tech Stack
I decided to keep the project lightweight and performant. Here is what I used:
- Frontend: React with Vite for a fast development loop and efficient builds.
- Rendering: HTML5 Canvas API. While I could have built the wheel with CSS transforms, Canvas offered much better control over the frame-by-frame physics and drawing of custom segments.
- State Management: Simple React hooks to manage the list of options and the current rotation state.
- Deployment: Hosted as a static web app to ensure near-instant load times.
Technical Challenges: Faking Physics
The most interesting part of the build was getting the "feel" of the spin right. A simple linear deceleration feels robotic and fake. To make it feel natural, I had to implement a basic friction model.
Instead of just picking a random number and jumping to it, the app calculates an initial velocity based on the user's click. Each frame, that velocity is multiplied by a friction coefficient (e.g., 0.98). When the velocity falls below a certain threshold, the wheel stops. Calculating exactly which segment is under the "pointer" at the top required mapping the final rotation angle back to the array index of the user's options, accounting for the fact that the wheel might have spun several full 360-degree rotations.
Lessons Learned
- UX over Features: In early drafts, I considered adding complex features like accounts or saved history. I realized these actually hurt the value proposition. The real value is speed—getting from "I can't decide" to "The wheel decided" in under ten seconds.
- The Importance of Accessibility: Using Canvas means the content isn't inherently readable by screen readers. I had to ensure that the results and the input forms were properly handled in the DOM so that the tool remains usable for everyone.
- The Power of URL Parameters: To make the tool shareable, I implemented a way to encode the list of options into the URL. This allows a teacher to set up a wheel of student names and simply bookmark that specific link for daily use.
Try It Out
Building this was a reminder that not every project needs to be a complex enterprise solution. Sometimes, the most helpful things you can build are the ones that solve a tiny, universal friction point in daily life.
If you have a debate to settle or a name to pick, feel free to give it a spin at https://spindecide.getinfotoyou.com. It is free, requires no account, and hopefully makes your next minor decision a little more fun.
I’d love to hear how you handle decision fatigue in your own workflow, or if you've tackled similar physics-based UI challenges in your projects!
Top comments (0)