Our dev team didn't buy their way out of a standup problem. They built their way out, with AI. Here's the story, and what it means for the work we do for you.
Every growing team hits the same wall. The rituals that worked at ten people quietly stop working at twenty.
For our development team, that wall was the daily standup. A 30-minute meeting is plenty when you have a handful of engineers. Stretch it across 22 people, each answering what they worked on, what's next, and what's blocking them, and it falls apart. So the team did the sensible thing and moved most updates to written threads. That saved time, but it created a new problem. A blocker mentioned once on Monday would vanish by Tuesday. If someone had been quietly stuck on the same task for five days, nobody could see it. The board in Jira tracked how the project was doing, but not how the engineers were doing.
That gap between project health and team health is where the trouble hides. And it is exactly the gap Horus was built to close.
From reactive to proactive
Horus started with one goal: stop waiting for people to self-report that they're stuck. Product Manager at Moxie Labs, Mahmoud Eid and his team wanted to detect trouble early rather than discover it at the end of a sprint. The first version did something deceptively simple. It pulled each engineer's activity into a rolling three-day view, so the standup only had to ask one question, "What are you working on today?", and the tool filled in the rest of the picture automatically.
From there it grew. Horus now aggregates data from three systems the team already used: Jira for tickets, Clockify for logged time, and Notion for the transcribed to-do items that come out of every call. Blockers surface under each person and refuse to disappear, migrating from one day to the next until someone actually checks them off. Action items captured in a meeting don't get forgotten. And because time logged in Clockify is tied to ticket numbers, the team can finally answer a question that used to be guesswork: were our estimates any good?
The payoff shows up most clearly in the sprint-to-sprint view, which tracks velocity, story points, logged hours, and estimated versus actual time for the whole team and each engineer. Looking back across sprints, the team learned their real velocity sits around 280 points per sprint, so when they feel tempted to commit to 329, they now know better. Horus even breaks time down by category, development, new-feature bugs, legacy bugs, QA, and unplanned ad hoc work, so when a sprint runs long there's a clear reason why, and a clear way to prevent it next time.
"It became very easy for me to go to Claude and say, here's what I need. And when I saw how fast it could do it, and how exactly it matched my needs, I kept adding more."
Why build instead of buy
The obvious question is the one our co-founder and CSO, James Koran asked in the room: why not just buy something off the shelf? The team had tried. Tools like Looker Studio were too rigid, boxing them into a fixed list of widgets and a fragile web of connections. Nothing on the market did exactly what their process needed, in exactly the way they needed it.
Here is what changed the math. Connecting four or five separate systems into a custom dashboard used to mean months of developer time, a cost so high that most companies would never sign off on it, useful or not. With AI, the cost of building dropped, and just as importantly, so did the cost of failure. Mahmoud could start Horus as a side project without knowing whether it would work, because experimenting was suddenly fast. That is the shift worth paying attention to: AI didn't just make the tool faster to build, it made it safe to try.
The real unlock: expertise, not code
The most interesting part of the story isn't the dashboard. It's who built it. Horus works because it was built by the person living the problem, not handed off to a developer who had to be told what to build. As our team put it, deep experience carries a lot of knowledge you don't even realize you have. When you write requirements for someone else, that tacit knowledge gets lost in the handoff, like a game of telephone. When the expert builds it themselves, they notice "I need this" the moment they see the gap, and they fix it on the spot.
AI is what makes that possible. It puts the ability to build directly in the hands of the people who understand the work best. And it turns prototypes into the fastest way to align a team, because clicking around a real screen beats debating a document every time.
Why this matters beyond our team
There's a reason we're telling this story. The pain behind Horus is not unique to us. Nearly every team we work with struggles with the same things: fragmented reporting, no clear view of where time actually goes, and process roadblocks that quietly drain productivity. As AI accelerates how fast our own engineers ship, the volume of work has only grown, which makes visibility more important, not less. Burndown charts tell you how long a ticket took, but not the journey it took to get there, or where the real bottleneck was.
Notably, none of this required the team to change how they work. Horus fit around the existing habits in Jira, Clockify and Slack instead of forcing everyone to adopt a new system. That's the difference between a tool built for you and a tool you have to bend yourself to fit. And Horus is still growing, with QA velocity metrics and two-way syncing with Notion already on the roadmap.
This is the approach we bring to client work: use AI not to generate more noise, but to solve the operational problems that actually slow teams down. We build for outcomes, and we build hand-in-hand with the people who have to live with the result.
Introducing the AI Blueprint Sprint: A New Service from Moxie Labs
Speaking of quick iterations, I’m thrilled to announce a new service from Moxie Labs. The AI Blueprint Sprint offered by our dedicated AI-Transformation team is a time-boxed 2 week immersion into a problem-space within your organization. We’ll dive deep into the people, processes, and technology currently at the heart of the issue and map-out what’s working and what’s not. Then we’ll identify the opportunities we see and propose a set of AI-enabled optimizations leveraging a combination of cutting-edge AI tools and resources.
A typical engagement focuses on a single problem space, runs for 2 weeks and costs between $10K - $15K. Once you have your read-out in-hand you can decide to implement our recommendations yourself or retain our AI team to implement them and train your team.
If you’ve been looking for the right way to bring more rigor to your AI adoption, this could be the right next step. If you’re interested, reach out to us here to discuss your situation, and what happens next.
Think this might be a good fit for your team? Let's talk.
