Ship the UI you designed — not the one that slipped through CI

Functional tests answer one question well: “does the button do the right thing when clicked?” They are silent on everything that happens before the click — whether the button is the right colour, the right size, in the right place, readable on a 360-pixel screen, or visible at all after the latest CSS refactor. This is the gap where most release-day incidents actually live.

Real regressions we see, and that ScanU is designed to catch, tend to cluster around a handful of predictable triggers:

• A CSS refactor collapses a flex container’s gap on a single breakpoint. The desktop layout looks identical; on a 768-pixel tablet, two cards now overlap.
• A design-token bump nudges every spacing value by two pixels. Nothing fails; a dozen carefully balanced compositions quietly stop being balanced.
• A third-party widget — a cookie banner, a live-chat, an ad slot — ships a silent update that shifts the first paint. Core Web Vitals regress overnight with no code change on your side.
• A framework upgrade swaps the default font-feature stack. Copy reflows by half a line across long-form pages. Hero CTAs suddenly sit below the fold.
• A feature-flag rollout re-orders the DOM. On Safari, a modal’s stacking context changes and the close button becomes unclickable. On Chrome, it looks fine.

None of those break an assertion. All of them break a user. ScanU’s job is to make the second kind of breakage as easy to see, review, and block as a failing unit test. When the diff appears on the pull request, a designer can weigh in the same way a reviewer weighs in on a function signature — before the change merges, not after it reaches production.

That shift — from “hope someone notices in staging” to “review a visual change the way we review a code change” — is the core value of a visual regression testing tool in a modern release pipeline.

Every run is a three-step pipeline. First, ScanU navigates each browser engine to the page or component under test, waits for a configured set of readiness signals — fonts loaded, images decoded, network quiet, a data-ready attribute, or a custom JavaScript probe — and pins any CSS animations to their final frame. Second, it captures the page at every configured viewport in the same run, using scroll-stitching for long pages so you get the full artefact, not just the viewport fold. Third, it compares that capture to the accepted baseline and produces a per-(browser, viewport) result: identical, within tolerance, or meaningfully different.

The comparison itself is not a naive pixel diff. ScanU applies a perceptual model that understands anti-aliasing, subpixel rendering, and colour-space nudges, so a WebKit kerning quirk does not masquerade as a bug. It also supports explicit masks for the regions you know will change every load — live data, relative timestamps, randomised content, carousels — so those areas contribute zero noise to the diff.

When a real change appears, the platform shows you three synchronised panes: the baseline, the current capture, and a diff overlay that highlights exactly what moved. A single reviewable decision — accept, reject, or update the baseline — is recorded on each change, and that decision becomes part of the project’s history. There is no silent drift and no auto-acceptance: the baseline only moves when a human with permission says it should.

The same pipeline can be driven from three entry points: against live URLs (production, staging, PR previews), against a static site or built asset bundle, or against component previews in a Storybook-style sandbox. Most teams use the first for release gates, the second for deployment artefacts, and the third for design-system work — all feeding the same baseline store.

Whatever the shape of the team, ScanU is typically adopted for one of five reasons: a recent production incident that a visual regression would have caught; a design-system migration where the blast radius of changes is impossible to audit manually; a CI/CD workflow that needs a release gate richer than “tests passed”; a client-facing deliverable that needs before/after evidence; or a compliance posture that prefers EU-hosted tooling for testing assets. A shared CI/CD integration sits behind all five — the same pipeline does the work whether it is triggered by a PR, a merge, or a nightly schedule.

ScanU is built and hosted in the European Union, with storage and processing located on EU-operated infrastructure. For teams with data-residency commitments — regulated industries, public-sector buyers, privacy-sensitive B2B customers — that is frequently a procurement requirement, not a preference. ScanU is designed to satisfy that requirement without forcing a compromise on product capability.

A few deliberate design choices follow from that posture:

• Data minimisation. The platform stores screenshots and the metadata needed to diff them; it does not hoover up page source, cookies, or request bodies that do not contribute to the diff.
• Masking by default in sensitive contexts.Fields known to contain personal data — account headers, email addresses, order numbers — can be declared as masked regions so the captured image is already redacted when it is written to storage.
• Access control. Who can see a diff is a first-class permission. Reviewers, contributors, and external auditors get explicit roles, and every baseline update is logged with the user who authorised it.
• Processor transparency. The list of sub-processors is published and versioned. No hidden analytics pipeline sees your screenshots.
• Retention you control. Baselines and diff artefacts are kept for the horizon you configure; old runs expire automatically rather than accumulating silently.

For the full privacy posture — sub-processors, regional hosting, DPA, retention windows — see the GDPR and data-handling documentation. For most teams, the headline answer is the important one: your screenshots stay in the EU, and the platform is engineered to keep them that way.

Visual bugs cluster into a handful of recurring patterns. Each one looks trivial in isolation; each one can ship to production without a single red test. All of them get surfaced as a diff on the next ScanU run, before the PR is merged.

• Spacing shifts. A gap utility is bumped from 16 to 20 pixels; a card grid that once breathed evenly now feels crowded on mobile. The HTML is unchanged; the layout is not.
• Broken layouts after deployment. A build pipeline upgrade drops a PostCSS plugin that was responsible for autoprefixing backdrop-filter. On Safari, a navigation bar suddenly renders opaque where it used to blur.
• CSS regressions from specificity shifts. A tailwind class order change, a new utility layer, or a refactored cascade subtly alters which rule wins — a heading loses its accent colour on a handful of pages.
• Responsive breakpoints failing. A new nav item overflows the tablet breakpoint and wraps into a second row, pushing the hero below the fold on iPads and large Android phones.
• Rendering differences between browsers. A design that relies on text-wrap: balance is crisp on Chrome but still reads unbalanced on engines that have not shipped it. Without a cross-browser check, this is invisible on the developer’s machine.
• Font and typography drift. A font provider swaps a subset, weights shift by a hundred grams, and every paragraph on a marketing site re-flows by a quarter of a line. Copy density changes; no diff in the repository explains it.
• Third-party widget regressions. A consent banner vendor ships an update that makes the accept button invisible on dark themes. Your conversion rate drops; your tests pass.
• Design-system drift. A button component changes its focus-ring offset. Twenty consumers depend on that component. Twenty pages now look subtly off. Nobody reviews twenty pages manually.
• Visual bugs escaping to production. Any of the above, multiplied by the routes and breakpoints nobody opens on a given week, across the browsers nobody on the team uses daily.

The feature overview walks through the detection primitives in more detail — perceptual tolerances, masked regions, viewport scroll capture, baseline branching, and how each maps to one of the categories above. For most teams, the shorter story is: if it changes visually, ScanU will notice; if it is expected, you accept it in one click; if it is not, you have caught it before anyone else does.