Code health tooling for developers and small teams who want clear answers, not enterprise software.
In his book Your Code as a Crime Scene, developer and researcher Adam Tornhill made a deceptively simple observation: the files most likely to cause production incidents aren't just the complex ones. They're the complex ones that also change constantly.
A complex file that nobody touches is manageable — it's stable, even if it's hard to read. A simple file that changes constantly is fine — it moves fast, but it's easy to reason about. A complex file that changes constantly is where bugs live, where developers dread going, and where incidents originate. Tornhill called these hotspots.
That single idea — complexity × churn = risk — is the foundation of everything tugtug does. The visualizations, the alerts, the health score: all of them are different angles on that same question.
The established enterprise tools built around Tornhill's research are capable software. They're also built for enterprise buyers: YAML config files, plugins for each language, servers to maintain, and pricing that assumes a budget committee approves the purchase order.
tugtug is the version a solo developer or small team actually wants to use. Connect a GitHub repo. In under a minute, you get a complete visual analysis of where the real risk lives. No config files. No plugins. No infrastructure to operate.
tugtug is built by Ted through Warped Puppy LLC, based in Maine. Ted has been a professional software engineer for over twenty years — frontend, backend, and everything in between — and built tugtug to solve a problem he kept running into on every team he joined: no clear way to see which parts of the codebase were actually risky.
One person means a few things worth naming: there are no salespeople, no quarterly roadmap dictated by enterprise buyers, and no investor pressure to harvest data in exchange for a free tier. When something breaks, the person you email is the person who wrote the code.
The product runs on infrastructure chosen the way you'd choose it for your own most critical project: Vercel for serving, Supabase (Postgres with row-level security) for data, and GitHub's own OAuth for authentication.
Your source code is never stored. We read files to compute metrics — complexity, churn, duplication — then discard the source. Only derived numbers are stored: file paths, scores, and your codebase's health history over time.
Full details on encryption, data retention, GDPR rights, and how to delete your data are on the Security & Privacy page.
No account needed. Paste a GitHub URL on the home page and get a full analysis in under a minute.