← Back to portfolio

Independent product · shipped

BrowseWell

A browser-native attention-management system — not a website blocker, but a policy and intervention engine that operates across dynamic, SPA-driven sites. Live on the Chrome Web Store.

Executive summary

People who need the internet to work, not hypnotize them, are poorly served by binary site-blockers that break on modern single-page apps. BrowseWell is a Chrome extension (Manifest V3) that enforces attention policies at site, page, and element granularity, with intention checks, timed access, and deliberate overrides — all processed locally for privacy. I own it from concept through shipped product, including brand and the browsewell.app domain.

My role

Independent owner: product strategy, brand, architecture, and implementation. A shipped production product, not a prototype or spec.

Constraints

  • Chrome Manifest V3 service-worker lifecycle and permissions model
  • Dynamic, SPA-controlled DOMs that mutate without page reloads
  • Privacy: attention data must never leave the device
  • Performance: interventions must not degrade host-page responsiveness
  • Resilient element selection across sites that change constantly

Architecture

A policy and intervention engine layered over the browser, not a hard-coded blocklist:

Rule Definition (site / path / selector)
        ↓
Content-script lifecycle + SPA route detection
        ↓
DOM mutation observation
        ↓
Policy evaluation (intervention state machine)
        ↓
Intervention apply / pause / override
        ↓
Local storage + settings sync

Rules evaluate at three levels — entire site, page, and individual element — so useful functionality survives while distracting elements are suppressed. An intervention-state machine governs timed access, temporary pauses, and deliberate typed overrides rather than permanent disabling.

Key technical decisions

Context: MV3 restricts long-running background work to a service worker.

Decision: Stateless policy evaluation triggered by content-script events and alarms; persistent state lives in synced storage.

Tradeoff: Slightly more re-evaluation overhead in exchange for MV3 compliance and crash-safe state.

Context: SPA route changes don't fire normal page-load events.

Decision: History-API and mutation-observer based route detection to re-evaluate policy on view changes.

Tradeoff: More moving parts, but correct behavior on React/Vue/SPA sites where naive blockers silently fail.

Context: Attention data is sensitive.

Decision: All evaluation and storage is local; nothing is transmitted off-device.

Tradeoff: No cross-device cloud intelligence, in exchange for a privacy posture users can actually trust.

Reliability & quality

  • Resilient selector strategies that degrade gracefully when a site changes
  • Intervention-state machine with safe pause/override recovery
  • Performance-conscious content scripts to minimize host-page impact
  • Keyboard-accessible overrides and settings
  • Automated test matrix across representative site archetypes

Leadership & ownership

BrowseWell demonstrates independent ownership from concept through shipped product: identifying a real user problem, making product and monetization decisions, designing the architecture, and shipping to a public store with a branded product site.

Results

A shipped, publicly installable product with a finalized brand and dedicated domain — demonstrating browser-platform expertise, product engineering, state-machine design, and privacy-aware architecture end to end.

Retrospective

  • What I'd change: invest earlier in a broader cross-site test matrix to catch selector regressions before users do.
  • Intentionally deferred: cloud sync of rule sets — deferred to preserve the local-only privacy guarantee.
  • Next version: richer intervention analytics and shared, community rule packs.

Proof

Want to talk?

I'm open to senior product-engineering and technical-lead roles.

Get in touch