Smoothdev.io

Write Code, Not Docs

Visit Website
January 4, 2026 Why I’m working on Smoothdev

I’ve spent ~20 years in engineering and DevSecOps, mostly on teams that cared deeply about reliability, security, and shipping fast.

Across every team, one problem never really changed: documentation always lagged reality.

Commit messages were rushed. PRs lacked context. Release notes were a last-minute scramble (if they were written at all). And “we’ll document this later” usually meant never. Legacy projects became black boxes, why we made changes was lost, and the result is we spend hours, days, weeks, reading through code line by line trying to figure out how something works and why we built it that way.

Add to that the requirements in regulated industries for documentation for auditing and the hours spent last minute scrambling to update architecture diagrams, hunt down proper release note, prove change management change sets for evidence. We spend more time around trying to understand context and prove process than delivering features.

I didn’t want another dashboard, process, or tool engineers had to remember to use. I wanted documentation to come from the work itself, not as a separate task.

That’s why I started building Smoothdev.

Right now, we fopcus on change-based documentation: generating meaningful commit messages, PR summaries, and release notes directly from Git changes via a CLI. No UI to babysit. No context switching. It’s designed to stay invisible and fit into existing workflows.

Longer-term, the goal is simple: turn real engineering activity into trustworthy, durable and complete knowledge without asking engineers to slow down or change how they work.

We're still early, still learning, and actively shaping this based on feedback. If you’ve ever felt the pain of docs falling behind code, or hours spent trying to figure out how and why a project works, or ensuring there are audit artifacts for evidence I’d love your thoughts on where this should go next.

Comment

About

Docs always fell behind the code on every team I worked on, even when everyone agreed they mattered. The context lived in commits and PRs, but turning that into usable documentation was always manual and easy to skip.