Problem
About a third of every sprint commitment missed, and nobody could see why until someone burned out.
Nobody asked for a sprint tool. The whole team ended up running on it.
At Vettx I managed delivery for a development team of about fifteen that cost the company around $80K a month, and it finished roughly 65% of what it promised each sprint. Workload was invisible, estimates were guesses, and half the management lived in spreadsheets. None of that was anyone's job to fix. I made it mine.
- Role
- Delivery manager; designed and built it solo
- Year
- 2026
- Type
- Internal platform, B2B
- Stack
- Next.js, Supabase, Vercel, Claude API, Jira API
65→100%
of sprint commitments delivered
Solution
One hub with six modules and one login: live workload, refinements, retros, DevOps requests, holidays and admin.
Results
Delivery went from ~65% to ~100% of commitments, and 15 people ran their ceremonies in it.
Design challenge
How do you get a team to adopt a tool when nobody has the budget to approve it?
Issue #1
Overload was invisible in Jira, so I built workload you can see in the daily
Jira had all the data, but nobody opens twelve filters before a daily. Developers didn't push back on overload because they couldn't see it either. It wasn't a design ticket, a product ticket or an engineering ticket, so it just sat there.
The first module was Sprint Analytics: active sprint, history, planning and initiatives, with the load of each person on one screen.
Add screens or video here
Issue #2
A new tool would never get approved during cost cuts, so I shipped the first module on my own time
Pitching an internal tool to a company that was cutting costs was going nowhere. I built analytics in the evenings with my own tools and brought it to a daily.
Nobody had to approve a tool that already answered the question in the same meeting where people asked it.
Issue #3
Estimates were slow and noisy, so the AI got a confidence gate, not the last word
Claude reads each ticket blind, without points or votes, and rates its complexity against a frozen rubric. A small statistical model turns that rating into points. Below a confidence threshold, the ticket goes back to the humans.
I backtested it the boring way: calibrated on sprints 70 to 79, tested from 80 on. It plateaued around 80%, and people still agreed with each other more than with the model. So it became the opening estimate. That was the right job for it.
80%of estimates within one point
85%when the model was confident
74%baseline: always guessing 2 points
Add screens or video here
Issue #4
Management lived in five tools, so the hub became one login for every ceremony
Refinements with live voting and async check-ins, retros with lead evaluations, one DevOps request and approval chain, synced holiday calendars and per-capability permissions with a view-as mode.
It replaced a paid scrum poker tool and half a dozen manual chores. The PO started getting refinement prep before the meeting, not during it.
Add screens or video here
Results
What changed
Over the following sprints the team went from finishing around 65% of its commitments to landing at or above 100% almost every time. Workload got balanced before the sprint, instead of discovered when it failed.
~65% → ~100%sprint commitments delivered
15people using it every day
6modules, built solo
What I took from it
The most valuable problems are the ones with no owner. Nobody will hand them to you.
Internal tools don't need a mandate. They need to answer a question people already have, in the room where they ask it.
Vettx retired the hub in November 2026. It still runs as an archive on the last production snapshot.