PixellPeep: visual regression testing

A build log, not a sales page: the problem, the decision that shaped the product, and what building it taught me.

The problem

Functional tests confirm that a button works. They do not notice that it moved four pixels, lost its hover state, or disappeared behind a banner on one browser. Humans are good at judging a design and bad at spotting small, repeated visual shifts across dozens of screens on every release. Those breaks reach customers.

Who it is for

Engineering and QA teams shipping web interfaces who want visual checks inside CI, and teams in India who want to pay in INR without per-screenshot overage.

The decision that shaped it

Upload-first, CI-first. Teams can compare screenshots they already capture, or let PixellPeep capture URLs, and a single CI manifest turns dozens of screens into one pull-request check. Pricing is by plan and comparisons rather than per screenshot, so a three-browser CI run does not become a surprise bill.

Architecture and quality choices

  • Six comparison algorithms, from pixel-exact to perceptual, so teams can choose strictness per screen instead of fighting false alarms.
  • Diff heatmaps that show exactly what changed, not just a score.
  • A CLI and GitHub Action to fail the build on a visual regression, plus bulk CSV for large comparison runs.
PixellPeep home page

Honest status

Live since June 2026. We run PixellPeep on our own releases first. No public customer numbers yet; when there are real ones worth reading, they will be here.

How it informs my advisory work

It is the same quality-architecture thinking I bring to client teams: put gates in front of the journeys that matter, make captures deterministic so a green run means something, and fail the pull request instead of the customer.

Open PixellPeep