Why Frontend Quality Needs a Platform Frontend quality looks easy when one team owns one app. Someone changes a component, runs the tests, opens the page, and a reviewer says "looks good." Ship it. That works — right up until the UI stops belonging to one team. The button that broke somewhere else Picture a shared button component. Inside its own library, it's fine: default state works, hover works, disabled works, contrast passes, unit tests are green. Now drop that same button into a product page with a narrow sidebar, a dark theme, and a loading state. The label wraps badly. The icon shifts. The focus ring gets clipped by a parent container the button never knew existed. The component didn't fail. It passed every test it was given. The user still sees a broken screen. > Shared UI can be correct in the library and broken in the consumer. That gap — between "my tests pass" and "the person using it sees a broken screen" — is the whole problem this chapter exists to solve. Why the usual tests can't see the gap A normal test suite belongs to one repo. It knows that repo's routes, data, and setup — nothing else. That's fine for the question it's built to answer: The library can ask, "does this component behave correctly in my controlled environment?" A consumer app can ask, "does my app still work after the upgrade?" Neither one can ask the question that actually matters before a release: of the apps that depend on this, which ones does this specific change touch — and is it safe for all of them? That question crosses repositories no single test suite owns. It needs a shared layer that understands both sides: what the library changed, and what each consumer looks like. What changes when there's a platform Without a platform, every consuming team quietly reinvents the same testing problem: how to open the right pages, seed stable data, wait for the UI to settle, capture and compare screenshots, and decide what a failure even means. Ten teams means ten slightly different, half-maintained answers to the same question. With a platform, that repeated work moves into shared infrastructure once. The library team still owns its components. Product teams still own their apps. The platform just gives them a common place to state what "correct" means and get an answer — instead of everyone rebuilding the same screenshot harness from scratch. The output worth aiming for isn't a pass/fail badge. It's an answer to: what changed, where, is it expected, who should look at it, and can the release go ahead. That's a much stronger signal than "the screenshot test failed" — and it's the difference between a test suite and a platform. The rule > Frontend quality becomes a platform problem the moment shared UI needs checking inside real consumer contexts before it ships — not just inside its own library. Chapter 1 called this the "second team" moment. This chapter is what you build once you're past it. Next: what "safe" actually has to mean before any of this gets built.