Keystone

What do they actually do

Keystone is an early‑access tool that connects to a team’s GitHub, Sentry, and Slack/docs to help handle production issues. It collapses noisy Sentry alerts into a smaller set of “problems,” routes each one to the most relevant engineer using ownership and recent‑change context, and provides a single place to see errors, traces, recent deploys, repro steps, and impact. It can also run coding agents that draft pull requests you can review and continue editing locally in tools like VS Code/Cursor/Claude Code (homepage, YC profile).

The current workflow is straightforward: connect GitHub, Sentry, and Slack/docs; Keystone groups related alerts, assigns them with the “why,” and where possible proposes a draft fix as a PR for a human to review and iterate on before merging. The product is positioned as an assistant (not fully unattended), emphasizing draft PRs and human approval, with public docs labeled “coming soon” and access via early‑access sign‑up (homepage, YC profile).

Who are their target customer(s)

• On‑call engineers / reliability engineers: They’re overwhelmed by noisy error streams and often lack the right code or runbook context to fix incidents quickly. Keystone collapses alerts and surfaces related code, deploys, and repro steps in one place (homepage).
• Backend/service owners responsible for root cause and fixes: They spend time stitching logs, commits, and PRs before making a safe change. Keystone shows runtime context alongside recent changes and can draft a fix as a starting point (homepage).
• Engineering managers running on‑call rotations: They struggle to route issues to the right engineer and to demonstrate ownership and handoffs. Keystone learns ownership and assigns problems with the rationale attached (homepage).
• Platform/DevOps teams maintaining observability and deploys: They build and maintain custom glue between Sentry, Git, and chat. Keystone’s onboarding centers on GitHub/Sentry/Slack/docs to reduce that plumbing and centralize context (homepage).
• Security/compliance stakeholders at larger orgs: They worry about unattended fixes and need audit trails and approvals. Keystone is moving toward autonomous resolution with enterprise controls, signaling attention to governance (homepage, YC).

How would they acquire their first 10, 50, and 100 customers

• First 10: Founder‑led, white‑glove pilots via YC and personal networks. Time‑boxed, free pilots with hands‑on setup (GitHub/Sentry/Slack) and daily check‑ins to capture before/after metrics and feedback (homepage, YC).
• First 50: Hire a sales‑engineer to run concurrent pilots using a templated onboarding runbook; convert successful pilots into referrals and short case notes, and build 2‑page case studies and a 30‑minute demo for managers (homepage).
• First 100: Launch a self‑serve trial and list integrations where engineers search (GitHub/Sentry marketplaces); add an SDR/AE for larger pilots needing compliance controls; use early case studies to prioritize admin/compliance features and move larger pilots to paid (homepage, YC).

What is the rough total addressable market

Top-down context:

Keystone sits at the intersection of incident management/AIOps, observability, and developer productivity for teams running on‑call software services. Budgets here are typically carved from incident response, observability, and developer tooling rather than net‑new spend.

Bottom-up calculation:

Focus on teams with active on‑call and Sentry‑style error monitoring. If ~30,000 teams fit the ICP globally, with an average of 12 paying on‑call/service‑owner seats at ~$150 per seat per month, annual TAM ≈ 30,000 × 12 × $150 × 12 ≈ $650M.

Assumptions:

• Initial ICP is companies with 10–500 engineers using GitHub/Sentry/Slack and running 24/7 services.
• Seat‑based pricing around $100–$200 per on‑call/service‑owner seat per month.
• Adoption is limited to the on‑call/service‑owner cohort initially, not every engineer.

Who are some of their notable competitors

• Sentry: Error monitoring used to group and triage crashes; supports event grouping and ownership/auto‑assignment rules. Overlaps on alert grouping and ownership but does not draft code fixes (grouping, ownership).
• PagerDuty: On‑call routing and incident orchestration platform with automated workflows/runbooks. Overlaps on routing/automation and AIOps, but focuses on alerting/orchestration rather than generating draft PRs (incident management, automation).
• Datadog: Observability platform with AI‑driven correlation and incident management. Competes on automated triage and context aggregation; it’s primarily observability/ops rather than a code‑changing agent (AIOps correlation, incident mgmt).
• incident.io: Slack/Teams‑first incident management and service catalog that maps services to owners and runs chat‑native workflows. Overlaps on ownership/routing and coordination, not on generating draft fixes (Catalog, features).
• FireHydrant: End‑to‑end incident platform with service catalogs, automated runbooks, and AI summaries/retros. Closer on workflow automation but focused on orchestration/post‑incident processes, not automated PRs from live errors (runbooks, docs).