Hey everyone! I built Specsight because of something I experienced at every company I joined - the first few weeks were always the same. I'd ask "how does this feature actually work?" and get a different answer from every person. The docs were outdated, scattered across wikis, Notion pages, and Slack threads. Nobody could confidently tell me how something behaves right now. And it wasn't just me. PMs couldn't see what shipped without asking a developer. Customer success had to guess - or escalate to engineering - when a customer asked how something works. Everyone was waiting on the same people for answers that should have been available to the whole team. The frustrating part? The answer was always there - in the code. But unless you're a developer, you can't read it. So I built Specsight. It connects to your repo, reads the code, and generates a complete spec of every feature - written in plain English that anyone can understand. When your team ships an update, the spec updates itself. No one has to write or maintain anything. It also generates change reports so you can see exactly what changed between any two dates, flow diagrams that show how features connect to each other, and a changelog that tracks every evolution of your product over time. I built this for the PMs who compile release notes manually, the customer success teams who answer questions based on outdated docs, and the new hires who spend weeks just figuring out what the product does. Would love your thoughts - when your team ships a feature, how do the non-engineers find out what actually changed?

Specsight

Product specs that stay in sync with reality

Product specs that stay in sync with reality