Most SaaS teams treat UAT as a final checkpoint. Design ships, engineers build, and QA (or someone with a spreadsheet) walks through the flows before release and flags what's broken. It's a familiar process, and it sounds reasonable. You're checking the work before it reaches users.

The problem is that manual UAT doesn't scale with product complexity, it doesn't run on every deploy, and most importantly, the results depend on who's doing it and how much time they have. Bugs that a tired person misses on a Friday afternoon reach production. A small backend change breaks a flow nobody thought to retest. The spreadsheet feels like a safety net, but it has holes.

But there's a deeper issue the "let's automate our tests" conversation usually skips. The question isn't just how you test. It's what you test, and who decides that. And I'd say that's a product design decision.

The test suite is a design artifact

When you sit down to write end-to-end tests for a SaaS product, the first thing you have to do is define the critical paths: the flows that, if broken, mean the product has failed. Not failed in a minor way. Failed in the way that makes a user churn, file a support ticket, or lose trust in the product entirely.

That definition is a UX decision. You need to understand users well enough to know which flows they depend on for their core job, and which failures are annoying versus which ones are catastrophic. An engineer can write the test once the path is defined. Defining the path is design work.
‍

Most teams never make this explicit. Tests get written by whoever has time, covering whatever flows come to mind, with no way to prioritize. You end up with a suite that covers a lot, but not necessarily the right things. And when something important breaks, you hear about it from a user, not from the pipeline.

Defining what cannot break is one of the most consequential product decisions you can make. It forces clarity about what the product actually is, for whom, and what it promises.

How to think about critical paths

A critical path isn't just a happy path. It's a flow where failure has a real cost, for the user, for the business, or for trust in the product. In practice, I find them by asking a few questions for every major feature area:

Going through these questions gives you more than a test plan. It gives the team a shared definition of what the product promises. Most teams only realize they never agreed on that when something breaks and nobody agrees on how serious it is.

What this looks like in Playwright

Once the critical paths are defined, turning them into Playwright tests is fairly direct. Playwright simulates what a user does (navigating, clicking, filling inputs, waiting for responses) and checks that the result matches what was designed. The test reads like a user flow because it is one.
‍

Here's what a critical path test looks like for a multi-role form submission, where role-based visibility rules mean different users can see and edit different fields:
‍

That second point matters a lot. A common mistake in E2E testing is only checking that the UI looks right, like the button being hidden or the field disabled, without checking that the action behind it is actually protected. Those are two different guarantees. If you mix them up, your tests pass while real permission problems go unnoticed.

‍

For me, the biggest shift was realizing that deciding what cannot break is part of designing the product. Once that's written down as tests, it stops depending on memory, or on who happens to check before a release. The product keeps its promises every time it ships, and that's a user experience too.