We use Cypress mostly on projects that already have it. A working suite your developers know is worth more than a migration to our preference, so we improve what exists before proposing a replacement.
Fixing an inherited suite
The first pass is triage. Which tests have failed intermittently in the last hundred runs? Which have never failed and never could? We delete the tests that assert nothing, stabilise the ones covering real journeys, and quarantine the rest so the pipeline gives an honest signal from week one.
Component tests as the middle layer
Cypress component testing is a good fit for the pieces with real behaviour — a multi-step form, a filter, a date picker. Those run fast, do not need a full environment, and catch the class of bug that unit tests miss and end-to-end tests find too late.
Network control
Intercepting requests makes tests deterministic. We use it for third parties and error states, and we keep a small set of genuinely end-to-end tests that talk to real services, because a suite that stubs everything eventually tests only its own stubs.
Runtime matters
A suite nobody waits for is a suite nobody trusts. Parallel runs, sensible retries on genuinely non-deterministic boundaries, and a critical subset that finishes in a few minutes on every pull request.
When we would suggest moving
Multi-browser coverage, multiple tabs or origins, and mobile emulation are places Playwright is simply stronger. If those matter to your product we will say so, with an estimate rather than an opinion.
Both run in CI/CD under the approach set out on QA and testing.