Inspector

What do they actually do

Inspector is a browser-based tool that lets front‑end engineers capture the exact runtime context of a page—visual element selections/screenshots and relevant console logs—and pass that context to AI coding agents. The product is in early access behind a waitlist, and public materials describe a very small team (YC lists two people) building an “AI IDE for front‑end” that runs in the browser (site, YC page).

Typical use: select a UI element, add its DOM/code and one‑click console logs to the same context, then ask an agent to explain, fix, or suggest a change without manually assembling screenshots or stack traces. Inspector’s focus is packaging visuals + DOM + logs so agents operate with the same context the developer sees in the browser (site, founder post).

Who are their target customer(s)

• Front‑end developer fixing UI bugs: They spend time copying screenshots, console output, and component code between the browser and editor to explain a problem, which slows diagnosis and repair. Inspector aims to surface those elements and logs directly in the agent’s context (site).
• On‑call / production triage engineer: They often lack the exact visual state and runtime logs needed to reproduce a customer‑reported UI failure, wasting hours on repro instead of the fix. Inspector captures visuals + logs from the live page to shorten that loop (site).
• Engineer doing small visual changes or experiments: Hunting for the right file, running the app, tweaking, and refreshing for small fixes makes tiny edits slow. Linking visible elements to agent suggestions promises quicker feedback (YC page, site).
• QA/test engineer documenting regressions: Creating clear bug reports requires consistent screenshots, selectors, and failing console output; manual capture is error‑prone. Inspector’s element screenshots and one‑click log capture target this pain (site).
• Small team or startup frontend owner: With limited engineers and no separate QA, context switching between investigating, explaining, and fixing UI issues eats time. A browser‑centered tool that bundles visual state and logs with suggested edits reduces handoffs (YC page, site).

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

• First 10: Hand‑pick 10 front‑end engineers from the waitlist and YC/startup network for free early access, with 1:1 onboarding and pairing to capture real bugs; turn wins into 1–2 short case studies (site, YC page).
• First 50: Use those case studies and recordings for targeted outreach to engineering managers at startups, agencies, and on‑call teams; run 2–4 week paid pilots with clear success metrics and host live demos/office hours to lower onboarding friction.
• First 100: Remove the waitlist, offer a simple browser install and one‑click capture flow with in‑product guides/templates; let teams trial, then self‑upgrade to paid plans. Use referral credits and published pilot results to reach more small teams.

What is the rough total addressable market

Top-down context:

A realistic user-count TAM is roughly 13M–29M developers who work on or touch web/front‑end code today, derived by multiplying global developer totals by the share who used JavaScript in the past year (Evans/Statista, JetBrains, SlashData, Stack Overflow 2024).

Bottom-up calculation:

Low: 20.8M × 62.3% ≈ 13.0M; Base: 28.7M × 62.3% ≈ 17.9M; High: 47.2M × 62.3% ≈ 29.4M (JetBrains, Statista/Evans, SlashData, Stack Overflow 2024). Revenue TAM = user count × annual price per seat.

Assumptions:

• JavaScript usage is a reasonable proxy for work that involves front‑end/browser code.
• Professional developer counts (vs. hobbyists) approximate the pool of potential users for an AI IDE.
• Seat-based pricing applies to individual developers; adoption rates are not included in the TAM.

Who are some of their notable competitors

• LogRocket: Records session replays with DOM, console, network, and Redux state for debugging. Overlaps on capturing visuals + logs, but LogRocket focuses on session replay and analytics rather than an in‑browser AI IDE that proposes code edits (product, docs).
• FullStory: Reconstructs user sessions from DOM events and shows console/network info to reproduce UI problems. It’s oriented to digital‑experience analytics and support workflows, not live AI assistants that act on selected elements and generate code changes (session replay guide, console docs).
• Sentry (Session Replay): Links errors/performance events to short replays that include DOM state, interactions, and console entries. Core focus is error monitoring/observability and triage, not an AI‑first IDE for in‑browser element‑driven code suggestions (product, docs).
• Replay.io: A time‑travel debugger that records app execution (DOM, console, React internals, network) for deterministic replay and inspection. Emphasis is on recording and debugging (and CI/test integration), not primarily on an in‑browser AI agent proposing code patches (site, docs).
• Rookout: Lets engineers set non‑breaking breakpoints to fetch live snapshots from running services for faster debugging. Targets backend/production diagnostics rather than visual DOM selection and AI coding agents in the browser (overview, docs).