BrowserBook

What do they actually do

BrowserBook is a developer‑focused IDE for building and running browser automations. You write TypeScript/Playwright code in notebook‑style cells and execute it against a hosted, fully interactive browser that’s embedded in the IDE. Output (logs, data, screenshots) is shown inline, and the product includes helpers for login/auth (including TOTP), screenshotting, and data extraction, plus an API to run completed notebooks from other systems docs/product and launch materials.

The IDE includes a context‑aware coding assistant that can generate selectors and snippets based on the page you’re looking at. It’s positioned for developers who want deterministic, debuggable scripts rather than point‑and‑click RPA. Scheduling and fuller deployment/observability features are on the roadmap; today you can author and run notebooks in the hosted browser and trigger them via API, with scheduling/production‑suite features noted as “coming soon” in the docs (docs, Product Hunt).

The company is early (YC Fall 2024) and has started engaging regulated customers; their trust portal references SOC 2/HIPAA work in progress, signaling a push toward enterprise readiness (YC profile, trust portal).

Who are their target customer(s)

• Developers building agent-backed workflows that need reliable web actions: LLM agents often fail on multi-step web UI tasks; teams need reproducible scripts they can debug and call reliably from agents or backends (Product Hunt, docs).
• QA / end‑to‑end test engineers: Flaky tests and slow feedback loops across local and CI environments make failures hard to reproduce and expensive to maintain (YC profile, docs).
• Data extraction / scraping engineers: Keeping scrapers working as sites change and handling authenticated sessions is repetitive and breaks frequently; selectors and login flows need constant updates (Product Hunt, docs).
• Healthcare or other regulated teams automating sensitive workflows: They need strong security, auditability, and compliance (e.g., SOC 2/HIPAA) before putting automation into production paths (YC profile, trust portal).
• Small engineering teams/startups avoiding browser infrastructure ops: Standing up and maintaining Playwright/browser instances and CI hooks is time‑consuming and distracts from product work (docs, Product Hunt).

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

• First 10: Founder‑led pilots via healthcare contacts and YC/network intros; co‑build initial notebooks and run live onboarding to validate needs and compliance blockers (YC profile).
• First 50: Publish ready‑made notebooks/templates (login+scrape, E2E test, agent actions) and promote via Product Hunt, Playwright/TypeScript forums, GitHub, and demos; hold weekly office hours to convert evaluators (Product Hunt, docs).
• First 100: Short paid pilots for high‑value trials with onboarding, reliability targets, and access to compliance materials to win regulated customers; pursue QA/CI integrations and partnerships, and expand outbound to QA and data teams with roadmap/case studies (docs, trust portal).

What is the rough total addressable market

Top-down context:

BrowserBook sits within developer‑led browser automation and testing, overlapping the global automation testing market (about $17.7B in 2024) and the web scraping market (~$1.0B in 2024), with adjacency to RPA (estimates range from ~$3.8B software/services in 2024 to higher depending on scope) (automation testing, web scraping, RPA Grand View).

Bottom-up calculation:

Near‑term, focus on teams already writing Playwright/Cypress automations and scrapers. If 25,000–50,000 teams globally adopt a hosted dev‑first IDE for browser automation and spend $3k–$12k per year (3–10 seats at ~$100/month), that implies a $75M–$600M initial TAM for BrowserBook’s current product scope. Playwright’s growth (now surpassing Cypress in npm downloads) supports the size of this developer base (Checkly blog on npm trends).

Assumptions:

• Targetable teams are a fraction of those running E2E tests/scrapers; estimate 25k–50k teams globally.
• Average paid usage is 3–10 developer seats per team at ~$100/seat/month (or equivalent usage‑based spend).
• Excludes broader RPA/no‑code buyers; expansion features (scheduling/observability/compliance) could increase ARPU beyond these estimates.

Who are some of their notable competitors

• Playwright: Open‑source browser automation and test runner (TypeScript/JS/Python/.NET/Java). Powerful inspector, tracing, and codegen, but you manage local/CI infra yourself; no hosted notebook IDE like BrowserBook offers (docs).
• Apify: Cloud platform for web scraping/automation with "Actors," scheduling, data storage/exports, proxy/unblocking, and a marketplace. Strong for scraping pipelines and orchestration; less about an inline TypeScript notebook IDE for Playwright scripting (platform/docs).
• Browserless: Browsers‑as‑a‑Service for Puppeteer/Playwright sessions, with stealth/captcha handling and REST endpoints for screenshots/PDFs. Removes browser infra pain but is a lower‑level runtime vs. an IDE with inline cells and AI context (docs).
• Cypress (and Cypress Cloud): Popular E2E testing framework plus cloud dashboard for recording/replaying tests, parallel CI, and analytics. Competes for QA teams reducing flakiness/CI pain, but uses its own runner/UX rather than a hosted Playwright notebook IDE (Cypress Cloud).
• Ghost Inspector: No‑code/SaaS for recording, scheduling, and running browser tests with visual comparisons and alerts. Targets codeless QA/monitoring; contrasts with BrowserBook’s developer‑first TypeScript/Playwright authoring (features/docs).