Project Planning Tools
Off-the-shelf planning tools either over-complicated what we needed or couldn't match our process. So we built two apps from scratch: Poker for collaborative estimation and Epic for iteration and milestone planning. They were tightly integrated and used daily by our own team.
- Three-point estimation with weighted means and simultaneous reveals
- Clean export view with a normal distribution curve plus timeline and cost projections
- Led the Redis + PubSub integration to keep realtime features reliable during our Kubernetes migration
- Seamless sync between Poker and Epic via REST APIs and WebSockets
- Drag-and-drop that felt completely natural
- Ongoing performance work as projects grew to thousands of rendered stories
Full Story
Clean Coders Studio is the software contracting company where I spent several years. Like most agile teams, we estimated stories and planned week-by-week iterations—but we had some pretty strong opinions about how those things should actually feel.
Every existing tool we tried either added a ton of baggage we didn't need or couldn't bend to fit our process. So rather than force ourselves to adapt, we decided to build our own.
Poker gave us Planning Poker with more nuance. Instead of everyone throwing out a single number, each person privately submitted three estimates: Optimistic, Realistic, and Pessimistic. The app calculated a weighted mean for each of us, then averaged those into one final story point. It worked great internally and was especially handy in client discovery meetings — quickly giving non-technical founders a realistic sense of timeline and cost for the whole project.
Those estimates flowed straight into Epic. Epic kept planning clean and flexible: stories lived under milestones and could be dropped into iterations. Clients could review story details in one place before signing off on completed work.
The two apps stayed perfectly in sync. Poker and Epic communicated through REST APIs, while most user interactions happened over WebSockets.
Some of the most interesting work was in the details. Making drag-and-drop feel truly natural took real care. As projects grew to hundreds or thousands of stories, keeping the interface fast became an ongoing focus. When we moved toward Kubernetes, I led the integration of Redis for distributed locking and PubSub messaging — which was essential for keeping the realtime features reliable across instances.
I joined both projects early on and had a hand in nearly every feature. I turned UX designs into working code, built backend services, worked directly with the product owner on priorities, and — during stretches when I was the most senior developer — mentored apprentices rotating through the team and helped guide technical direction.
Because we used these tools every day on actual client work, the feedback loop was immediate. If something felt slow, clunky, or missing, we felt it firsthand and fixed it quickly. The result was a pair of tools that fit our process perfectly instead of forcing us to adapt to someone else's.
These apps have powered smooth project delivery for years at Clean Coders Studio, and they’re still a great example of what happens when you build software specifically for the people who use it.