Devlogs: Building an Internal Task Tracker with Claude
We're back with another Devlog entry this month! This time, we focus on streamlining a Task Tracker system for the Studio. Truthfully, we've used a lot of task tracker brands over the years and at times, the app works against you. Eventually, with Claude, I realize I can build a system that accurately fits the needs of the Studio, factor in our previous experiences with trackers we've used before, and ensure Departments are empowered to collaborate with each other.
The problem
Nobody could look at one place and see the shape of what the studio was doing. None of the old trackers we tried gave us the flexibility to standardize how we understood our own work in a visual way. ClickUp was overwhelming, too many views, too much setup, people bounced off it. Slack comms just get flooded, anything important scrolls off in an hour. Coda (now Superhuman Docs) actually came closest, I still use it for a lot of our docs, but it fell apart the moment work needed to be understood across multiple documents at once.
The solution
I built our own tracker with Claude Code instead of forcing another SaaS tool to do something it wasn't built for: Multi-tenant Supabase backend, real auth, the works. But the part that actually made it useful was letting the team's own requests shape what views existed. People started asking for pipeline views, deadline views, campaign views, RACI matrices, and each request pushed the tool closer to something built for how departments actually need to collaborate with each other, not just track their own tasks in isolation. The tracker, as it updates, is shaped by the users' behavior and preferences.
How the team responded
They shaped it as much as I built it. Three things kept coming up whenever someone asked for a new view or pushed back on an existing one:
Simplicity - The tool should stay out of sight and out of mind until the moment it actually matters.
Cross-department visibility - Why should marketing be blind to feature progress when they need it to plan a campaign around the actual ship date?
A real visual graph of pipeline flow - so anyone could look at a project and immediately see where the work physically sits and avoid lots of ticket statuses.
How it felt going through this process
The tool kept teaching me what the studio actually needed, instead of me guessing at it upfront. Every request for a new view was basically someone telling me where the old way of working had been quietly failing them. That's a good problem to have as a director, people trusted the tool enough to ask it to do more.
What stuck with me
The realization that the actual gap was never "we don't know what's happening." It was "we don't have a shared visual language for what's happening." Once departments could see pipeline, deadlines, and campaigns in the same place, cross-team planning stopped being a guessing game. Marketing stopped finding out about ship dates secondhand. That's a bigger shift than it sounds like on paper.
Key insights
The true problem was the lack of a shared visual standard for understanding work across departments.
Letting the team request views (i.e., pipelines, deadlines, campaigns, RACIs) shaped the tool into something built for cross-department collaboration, way beyond just personal or team task management.
Three pillars kept the tool honest: stay simple and out of the way until it matters, make cross-department dependencies visible, and show pipeline flow as an actual visual graph.
