← Selected workLINT UI · UI QUALITY · 2026—NOW

Making interface quality part of the development loop.

Lint UI is an open-source, local-first quality gate I am designing and building to catch visual regressions, responsive layout defects, and accessibility problems in the same workflow developers already use to catch problems in code.

RoleCreator · Design Engineer
StackTypeScript · Playwright · axe-core
Statusv1 · Active dogfooding
SourceGitHub
lint-ui run4 routes · 4 viewports
VISUALBaseline comparison 16 / 16 stable
LAYOUTResponsive bounds No overflow
ACCESSIBILITYaxe-core Serious contrast issue
report.htmlreport.jsonexit 1
THE PROBLEM

UI can ship faster than people can reliably review it.

Modern frontend work is increasingly fast, especially when AI is involved. A screen can move from an idea to working code in minutes, but the quality checks around it are still often manual: resize the browser, inspect a few routes, notice what moved, and hope nothing subtle broke elsewhere.

I wanted UI quality to behave more like code quality: explicit, repeatable, local-first, and able to run in CI. The product started as a visual-regression prototype, then narrowed into a more trustworthy v1 contract around visual comparison, high-confidence layout checks, accessibility, evidence, and predictable exit behavior.

BUILDING THE PRODUCT

From prototype to a quality gate I can trust.

01

Visual regression

Record approved baselines, capture deterministic screenshots across routes and breakpoints, and separate pixel sensitivity from the amount of visual change allowed.

02

Layout checks

Focus v1 on high-confidence defects: horizontal overflow, elements outside the viewport, and clipped text rather than broad heuristics that create noise.

03

Accessibility

Run axe-core in the same pass, preserve actionable rule evidence, and let projects decide which impact levels should fail the gate.

04

Evidence & reporting

Keep current screenshots, diffs, selectors, bounds, JSON results, and a self-contained HTML report so a failure explains what happened.

05

CI behavior

Use predictable exit semantics for quality failures versus execution errors, with a GitHub Actions path that can start non-blocking while a project builds confidence in the signal.

06

Honest scope

Remove or reject configuration that is not implemented. Authenticated flows, hosted review, token enforcement, and noisy heuristics stay out of v1 until evidence justifies them.

DOGFOOD EVIDENCEBuild → run → inspect → fix
local + CI
16/16unchanged browser cases passed in the first visual acceptance run
77–89%diff range when a deliberate background regression was introduced
3real accessibility problem types caught in the demo and report self-test
0violations after fixing the report and rerunning its own checks
DOGFOODING

The product is being shaped by using it, not by imagining the workflow.

I am actively running Lint UI against the things I build, including this portfolio. The Antid repository keeps approved visual baselines in Git and runs the gate in GitHub Actions while dogfood sessions continue to accumulate. That makes the portfolio both a project and a test target.

The loop has already changed the product. A below-fold check was left out after it produced noise on mobile. The HTML report was then tested by Lint UI itself, exposing contrast, landmark, and mobile overflow problems. Those defects were fixed and the same checks passed on the rerun.

Evidence changes the product contract. Features stay narrow until they are trustworthy enough to become part of the gate.

PRINCIPLES
01

Quality belongs in the implementation loop.

UI review should happen where code is built and checked, not only after a handoff or before release.

02

Trust is more important than feature count.

A narrow check with clear evidence is more useful than a clever heuristic developers learn to ignore.

03

Dogfood before expanding the promise.

Use real projects to find false positives, workflow friction, and missing evidence before turning an experiment into a feature.

CURRENT STATE

Lint UI is still in active v1 dogfooding. The core now combines visual regression, responsive layout checks, accessibility validation, local artifacts, and CI-oriented result semantics. The case study will evolve with the product rather than pretending the experiment is finished.