Specsight
Product specs that stay in sync with reality
Start new thread
Ola Piętka

Specsight - Product specs that stay in sync with reality

by•
Every team has the same problem: nobody knows what the product actually does today. The spec is outdated or doesn't exist. So people ask engineers - and wait. Specsight reads your code and writes a complete spec of every feature. When your team ships, the spec updates itself. No manual writing. No stale docs. The best, up-to-date documentation already exists - it's the code. Most people just can't read it. Specsight makes it readable for PMs, customer success, and everyone else in your team.

Add a comment

Replies

Best
Ola Piętka
Maker
📌
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?