ObserveOne

ObserveOne watches web applications for the teams that build them. You give it a URL; it explores the site, plans test scenarios, writes Playwright tests and runs them on real browsers. It also monitors uptime, APIs and scheduled jobs, and publishes status pages.

I worked across the whole product in a small engineering team: the React dashboard, the Node.js API, the background workers, the public status page and the Python service that drives the AI browser.

Monitoring

• Four kinds of check. I built the create, edit, list and delete flows for heartbeat monitors, URL monitors, API checks and AI browser checks, with validated forms in the dashboard and matching endpoints in the API.
• Multi-region checks. URL and API monitors run from several regions. I built the worker service behind this on BullMQ and Redis, and the per-region charts in the dashboard.
• Dashboard. The overview with its checks table, statistics, grouping, and the mute and alert controls on every check.

Playwright Autopilot

This is the feature the product now leads with, and where most of my later work went.

• From a URL to a test suite. A crawl agent explores the application, and the platform generates a Playwright suite from what it finds. I built the suite management in the API and the interface to create, run and review suites.
• Running tests. Suites run in parallel in isolated sandboxes, on a schedule or on demand. Runs can be cancelled safely and replanned.
• Tests that keep working. Scripts are editable and versioned, and a healing step repairs a test when the page it targets changes.
• CI/CD. Integration with a GitHub App and its Checks API, GitLab, and inbound webhooks, plus the settings screens for them.

AI browser checks

• Browser service. In the Python service I worked on the browser pool, streaming of run logs through Redis, and tracking of token usage and cost per run.
• Seeing what happened. Video recording of each run with playback and download in the app, and a live view of the browser while a check runs.

Status pages, incidents and notifications

• Status pages. The public status page application and the screens to manage it.
• Incidents. Incidents that open when a monitor fails and resolve when it recovers.
• Real-time updates. I moved live updates from server-sent events to Socket.IO and built the notifications screens.

Billing, email and quality

• Billing. Subscription plans, usage limits and statistics, invoice history and payment methods.
• Email. A redesign of every transactional email template.
• Quality. Unit tests that took the API past its 80% coverage threshold, an accessibility and error-handling pass over the dashboard, and tighter row-level security in the database.