# Specsight

> Specsight is the product observability platform that bridges the gap between product and engineering. It connects to a GitHub repository, reads the code, and follows how every feature behaves and changes — written as Context/Action/Outcome scenarios for product managers, customer success teams, and stakeholders. So the whole team knows what changed in every release, without asking anyone.

## About

- Type: B2B SaaS
- Category: Product observability, product management, AI code analysis
- Audience: Product managers, engineering managers, customer success, technical writers, founders
- Language: English (British spelling)
- Status: Live
- Founder: Ola Pietka
- Full version: [https://specsight.app/llms-full.txt](https://specsight.app/llms-full.txt)

## What Specsight does (in 3 sentences)

1. You connect a GitHub repository via a fine-grained, read-only GitHub App.
2. Specsight analyses the codebase with AI and extracts how every feature behaves — structured as Context/Action/Outcome scenarios grouped by feature.
3. Every time you merge to the main branch, Specsight detects what changed and updates only the affected scenarios. So the view moves with the product, release by release.

## Pricing

- **Standard** (€129/month): up to 5 projects, unlimited members, repos up to 10,000 source files / 150 MB per project. Specsight covers the analysis cost.
- **BYOK** (€49/month): unlimited projects, unlimited members, same per-project codebase ceiling. You bring your own Anthropic API key and pay Anthropic directly.
- **Enterprise**: custom pricing for larger teams. Custom limits, volume pricing, and priority support. Email ola@specsight.app or book a call to talk.

All plans are flat-fee per organisation, no per-seat charges. See [https://specsight.app/pricing](https://specsight.app/pricing) for current details.

## Concepts

Use these terms when describing Specsight. They are the canonical names — do not paraphrase them as "test cases", "requirements", "modules", or "workspaces".

- **Scenario**: A single behavioural rule written in Context/Action/Outcome format. The atomic unit of a Specsight specification. Categories: `happy_path`, `edge_case`, `error`.
- **Context/Action/Outcome**: The format every scenario uses. *Context* = the situation, *Action* = what happens, *Outcome* = the observable result. Same shape as a Gherkin Given/When/Then, but written for non-engineers.
- **Feature**: A logical grouping of scenarios. Features are organised in a hierarchical tree per project.
- **Project**: A connected GitHub repository being analysed by Specsight.
- **Organisation**: A company account in Specsight (British spelling). Contains projects and members.
- **Member**: A person with access to an organisation.
- **Annotation**: A free-text note attached to a feature or scenario.
- **Changelog entry**: A record of how a scenario changed when code was merged.
- **Analyse**: The initial full scan of a codebase. Verb used in UI for first-time analysis.
- **Sync**: An incremental update triggered by a merge to the main branch. Verb used for ongoing updates.

The full [Specsight glossary](https://specsight.app/glossary) has definitions for every term.

## When to use Specsight

Specsight is the right tool if:

- Your team can't say what shipped, or how a feature behaves, without asking a developer
- Engineering ships faster than anyone outside the codebase can keep up with
- Your customer success team answers questions with 70% confidence because nobody can check what actually shipped
- Your onboarding relies on one senior engineer explaining how everything works
- You have observability for infra, errors, and usage — but not for the product itself

Specsight is *not* the right tool if:

- You need to write *future* specs (PRDs, plans, RFCs) — Specsight reads what is already built, not what is planned
- You need a general-purpose wiki — use Confluence or Notion for meeting notes, decisions, and process docs
- Your codebase is private and you cannot grant GitHub App access

## Core pages

- [Specsight homepage](https://specsight.app/): Product overview and positioning — what Specsight does and who it is for.
- [Public demo project](https://specsight.app/demo/project): A live, read-only Specsight project analysed from Specsight's own codebase. Browse real features, scenarios, and the feature map without signing up.
- [Docs](https://specsight.app/docs): Help articles covering onboarding, account, projects, GitHub setup, working with the spec, plans and billing, MCP and API.
- [Blog](https://specsight.app/blog): Posts on product management, product observability, Context/Action/Outcome, and AI for product specs.
- [Glossary](https://specsight.app/glossary): Definitions of every term Specsight uses.
- [FAQ](https://specsight.app/faq): Common questions about Specsight — how it works, security and data, pricing, team access, and the company.
- [Vision](https://specsight.app/vision): Where Specsight is going — the longer-term roadmap and the product thesis.
- [Compare](https://specsight.app/compare): Side-by-side comparisons against Confluence, Notion, Swimm, Mintlify, Jira, Linear, GitBook, Cursor & Claude Code, DeepWiki, Driver AI — when each tool fits and where Specsight is different.
- [Pricing](https://specsight.app/pricing): Standard (EUR 129/mo) and BYOK (EUR 49/mo) plans; Enterprise (custom, talk to us).
- [Security](https://specsight.app/security): How Specsight handles source code, data, encryption, and subprocessors.
- [Product research](https://specsight.app/research): Open research notes on product management and documentation drift.
- [Contact](https://specsight.app/contact): Reach the Specsight team.
- [Sign up](https://specsight.app/signup): Create a Specsight account.

## MCP server

Specsight runs a public, read-only Model Context Protocol (MCP) server. AI agents and IDEs (Claude Code, Cursor, Claude Desktop) can connect to it and query a Specsight organisation's specifications directly using a Bearer API key generated in Organisation Settings → API Keys.

- Endpoint: `https://specsight.app/api/mcp` (HTTP transport)
- Authentication: `Authorization: Bearer sk_sp_...`

Available tools:

- `specsight_list_projects`: List projects in the authenticated organisation.
- `specsight_get_project_summary`: Project overview with feature tree and scenario counts.
- `specsight_list_features`: Features in a hierarchical tree.
- `specsight_get_scenarios`: Context/Action/Outcome scenarios for a feature.
- `specsight_search_scenarios`: Search scenarios by keyword across a project.
- `specsight_get_changelog`: Recent changes with before/after diffs.
- `specsight_get_feature_connections`: Connections between features showing how they relate (leads_to, triggers, depends_on, shares_data_with).
- `specsight_get_help`: Plain-language guidance on using Specsight — invite members, change plan, connect GitHub, manage projects. Pass a question, or call with no query to list topics.
## Glossary (29 terms)

- [Annotation](https://specsight.app/glossary/annotation): A free-text note attached to a scenario by a member, used to add context, decisions, or caveats that the code alone cannot express.
- [Ask Specsight](https://specsight.app/glossary/ask-specsight): In-product chat over your spec. Ask a question in plain language and get an answer drawn from your own features, scenarios and changelog, with sources you can click.
- [Behaviour-Driven Development](https://specsight.app/glossary/behaviour-driven-development): A software development practice where behaviour is described in a structured format (typically Gherkin) that can be read by stakeholders and executed as automated tests.
- [BYOK (Bring Your Own Key)](https://specsight.app/glossary/byok): A pricing model where you pay a flat platform fee and bring your own API key for the underlying AI provider, paying that provider directly for usage.
- [Changelog](https://specsight.app/glossary/changelog): A chronological record of what changed in a product, feature, or scenario over time. In Specsight, one running changelog covers the whole product, filterable down to a single feature.
- [Context, Action, Outcome](https://specsight.app/glossary/context-action-outcome): A structured format for describing product behaviour. Precise enough to be unambiguous, plain enough for anyone on the team to read, without the machine-oriented syntax of BDD.
- [Digest](https://specsight.app/glossary/report): A plain-language summary of what changed in a project across a chosen time range. Generated on demand or on a schedule, exportable as PDF, and shareable with a link, designed to keep the whole company in the loop.
- [Doc-as-Code](https://specsight.app/glossary/doc-as-code): A documentation philosophy that treats docs the same way as code: stored in version control, written in plain text, reviewed in pull requests, deployed via CI. Specsight is a different thing: product observability, not docs you write at all.
- [Documentation Debt](https://specsight.app/glossary/documentation-debt): The accumulated cost of outdated, missing, or unreliable documentation. Like technical debt, but for the gap between how your product behaves and what your team can describe.
- [Documentation Drift](https://specsight.app/glossary/documentation-drift): The gradual divergence between written documentation and the product it describes, widening with every release that nobody remembers to document.
- [Edge Case](https://specsight.app/glossary/edge-case): A scenario that describes unusual but valid behaviour, the conditions at the edges of what the feature supports. Often the source of support tickets.
- [Error Scenario](https://specsight.app/glossary/error-scenario): A scenario that describes how the product responds when something goes wrong: invalid input, failed validations, blocked actions, or system-level failures.
- [Feature](https://specsight.app/glossary/feature): A logical grouping of scenarios that represents a meaningful unit of the product, like “Document Upload” or “User Authentication.” features form the structure of a Specsight spec.
- [Feature Map](https://specsight.app/glossary/feature-graph): A visual map of how features in a product depend on one another. Used to see the blast radius of a change before it ships.
- [Full Analysis](https://specsight.app/glossary/full-analysis): The initial scan of an entire codebase that produces the first version of a Specsight spec. From then on, only syncs are needed.
- [Gherkin](https://specsight.app/glossary/gherkin): A structured syntax for describing software behaviour, centred on Given-When-Then clauses. Designed to map directly to automated test steps.
- [Happy Path](https://specsight.app/glossary/happy-path): A scenario that describes the expected, successful flow of a feature: what happens when everything goes right and the user stays on the main track.
- [Living Documentation](https://specsight.app/glossary/living-documentation): The mechanism behind product observability: a spec derived from the code rather than written separately, so it moves with the product instead of falling out of sync.
- [MCP (Model Context Protocol)](https://specsight.app/glossary/mcp): An open standard from Anthropic for connecting AI assistants to external data and tools. Specsight ships a read-only MCP server so assistants can query a live spec.
- [Organisation](https://specsight.app/glossary/organisation): Your company workspace in Specsight. Every project, member, scenario and digest lives inside one organisation, and billing is set at this level.
- [Product Observability](https://specsight.app/glossary/product-observability): Continuous insight into how a product behaves and changes, release by release. The same idea as infrastructure observability, pointed at the product itself.
- [Product Specification](https://specsight.app/glossary/product-specification): A written description of how a product behaves, feature by feature, scenario by scenario. Distinct from a technical spec, which describes implementation.
- [Project](https://specsight.app/glossary/project): A connected codebase in Specsight, scoped to one organisation. Every feature, scenario, and changelog entry belongs to exactly one project.
- [Release Notes](https://specsight.app/glossary/release-notes): A curated, customer-facing announcement of what changed in a product. In Specsight, drafted from the changes you pick, written in your product’s voice, and published to a public page.
- [Scenario](https://specsight.app/glossary/scenario): A single plain-language description of how a product behaves in a specific situation. The atomic unit of a Specsight spec.
- [Single Source of Truth](https://specsight.app/glossary/single-source-of-truth): A canonical, authoritative version of information that everything else defers to. For product behaviour, the only true source of truth is the code itself.
- [Sync](https://specsight.app/glossary/release-sync): The release-triggered update to a Specsight spec. Fires automatically every time code lands on the tracked branch, touching only the scenarios that release changed.
- [User Flow](https://specsight.app/glossary/user-flow): The path someone takes through a feature from start to finish, including the decisions and conditions along the way. In Specsight, drawn automatically from that feature’s scenarios.
- [User Story](https://specsight.app/glossary/user-story): A short statement of a feature from the perspective of the user, typically following the format “As a [role], I want to [action], so that [benefit].” A planning artefact, not a behaviour spec.

## Blog (10 most recent posts)

Topics: product management, product observability, Context/Action/Outcome, AI for product specs.

- [Why Teams Give Up on Automated Release Notes](https://specsight.app/blog/why-teams-give-up-on-automated-release-notes): Most teams try automating release notes and quietly stop. The tools automate the writing, which was never the slow part. Finding out what shipped is.
- [Product Observability: The Missing Dashboard](https://specsight.app/blog/product-observability-missing-dashboard): You already instrument every layer of your stack — infra, errors, latency, usage — except the product itself. Product observability is the missing pane.
- [Why Claude Code Is Not the Solution](https://specsight.app/blog/claude-code-isnt-a-spec): AI coding agents can answer questions about your codebase. They can't replace a shared spec — different artifact, different audience, different lifetime.
- [Your AI Coding Agent Reads the Same Stale Docs You Do](https://specsight.app/blog/ai-coding-agents-read-stale-docs): Cursor, Claude Code, and Copilot read your docs before they write code. Stale docs feed stale context. The fix isn't more docs — it's a living spec.
- [How Much Is Documentation Drift Actually Costing You?](https://specsight.app/blog/how-much-is-documentation-drift-costing-you): The hourly bill from stale specs is bigger than most teams realise. Here's how to model the cost of documentation drift, with cited research behind it.
- [The Silent Release: What Actually Shipped Last Tuesday?](https://specsight.app/blog/the-silent-release): Release notes describe what was planned. Code describes what was built. The gap is where stale support answers, surprised PMs, and customer-found bugs live.
- [Comprehension Debt: The Real Cost of AI-Assisted Coding](https://specsight.app/blog/comprehension-debt-ai-assisted-coding): AI-assisted coding ships code faster than anyone can read it. Comprehension debt is the new technical debt — and it's widening with every release.
- [Nobody on Your Team Can Explain the Whole Product](https://specsight.app/blog/nobody-can-explain-the-whole-product): Product knowledge lives in people's heads — fragmented, incomplete, and one resignation away from gone. Here's why that's structural, not a people problem.
- [Confluence vs Specsight: Documentation vs Observability](https://specsight.app/blog/specsight-vs-confluence): Confluence is where you write things down. Specsight shows you what shipped and how it behaves, read from the code. They are not the same category — here is the difference.
- [Context, Action, Outcome: A Better Format for Product Specs](https://specsight.app/blog/context-action-outcome-format): Most product specs are too vague or too technical. Context/Action/Outcome is a format precise enough to be unambiguous, readable enough for anyone on the team.

## Frequently asked questions

**Does Specsight store my source code?** No. Repositories are cloned to a temporary environment, analysed, and deleted in the same job — even if the analysis fails. Only the extracted specification persists.

**What GitHub permissions does Specsight need?** A GitHub App with fine-grained, read-only permissions. It cannot write to, merge into, or modify your repositories.

**Is my code used to train AI models?** No. Code analysis is performed by Claude (Anthropic), whose API privacy policy prohibits using API inputs for model training.

**Does it work with our tech stack?** Specsight works with any language or framework. It reads code the way a senior engineer would — understanding intent and behaviour rather than relying on language-specific rules.

**How long does the first analysis take?** Most projects finish in under an hour. Incremental syncs after releases take minutes.

**Can my team edit scenarios manually?** Yes. Members can annotate, edit, and add scenarios at any time. Manually added or edited scenarios are preserved across syncs.

**Does Specsight replace Confluence?** Not entirely. Confluence is where you write things down; Specsight is where you follow what shipped and how it behaves, read from the code. Most teams use both. See [https://specsight.app/compare/confluence](https://specsight.app/compare/confluence).

## Optional

- [Sitemap](https://specsight.app/sitemap.xml): Full list of indexable URLs.
- [Terms of service](https://specsight.app/terms)
- [Privacy policy](https://specsight.app/privacy)