About
The sprint board never matched the code.
Every team I have worked with had the same problem. The sprint board said "In Progress." The standup said "almost done." The sprint review revealed something different.
The information was never missing from the codebase. The code knew exactly what was done. A merged PR proved something shipped. A missing function proved something didn't. The problem was that nobody had a tool to ask it — so we ran standups instead.
I started building Waterline because I wanted to stop this. The team should know whether a ticket was actually done before the sprint review, not during it. I also felt that acceptance criteria should mean something, not just words in Jira that someone wrote and nobody checked.
The approach is simple: read the codebase, match each acceptance criterion to the code that satisfies it, return a percentage. Derived from the code your team already shipped.
The other thing that changed this was AI-generated code. When Cursor or Claude Code pushes commits, there's high volume and almost no narrative. The code moves fast and the ticket stays "In Progress" because no human remembered to update it. Waterline closes that gap regardless of who wrote the code.
Before starting Waterline, I spent years building software for product and engineering teams. I have shipped production systems, managed deployments, and sat through the same broken standups and reviews I am now trying to fix.
Waterline is currently in private early access. We are onboarding teams selectively so we can support each one properly. If you want to get early access, join the waitlist.
Questions, feedback, or just want to talk through the problem: hello@getwaterline.dev
— Daniel Franco, founder & engineer