Your organisation runs a shared browser grid several teams depend on: how do you decide whether the quote suite moves to Playwright?

## Frame it as a delta, not a beauty contest Tool comparisons answer "which is better?" A shared grid makes that the wrong question, because you are not choosing on a blank sheet: you are deciding whether a specific delta pays back inside a horizon you are willing to name, for one suite, inside an organisation where other teams share the fleet. A principal-level answer starts by refusing the framing and asking what is actually broken today. ## Gather the evidence before the opinions - **Flake rate** on the insurance-quote suite over the last quarter, and how much of it is environmental rather than test design. - **Mean time to diagnose** a red build, which is where tracing and network control would pay. - **Wall-clock time** and how much of it is queueing for a node versus executing. - **Coverage misses**: which required browser targets the current setup does and does not run. - **Who else is on the fleet**, and what its cost per team looks like if this suite leaves. If the evidence says the pain is test design -- order dependence, shared mutable data, assertions on timing -- then no runner change fixes it, and the migration will simply carry the problem across. ## Costs the tool comparison hides | Hidden cost | Why it bites | How to bound it | |---|---|---| | Second-toolchain tax | two skill sets, two CI paths, two dashboards | a dated coexistence window | | Blast radius on the fleet | a leaving team raises everyone else's share | agree the fleet's future first | | Re-learning curve | the suite gets worse before it gets better | port a slice with the real team | | Ownership vacuum | nobody owns the new pipeline at 3am | name the owner in the decision | Sunk cost is the classic trap in this decision. What was already spent on the grid is irrelevant; what it will cost to keep operating it is decisive, and those two numbers are easy to confuse in a room that built the grid. ## Prefer a reversible door 1. Adopt on **new tests only** for one or two releases, so the tool is proved on real work at real cost with no rewrite committed. 2. Port the hardest existing slice and let it run alongside the current suite. 3. Set a written trigger in advance: if the slice halves triage time and holds the browser matrix, the port proceeds; if not, you stay and spend the same budget on test design. 4. Review at the trigger date with the numbers, not with the enthusiasm. Most of this decision is a reversible door dressed up as a one-way one. Structuring it so that stopping is cheap is worth more than being right on the first analysis. ## When staying put is the correct call - The team's required targets include an engine or an operating system the bundled browsers do not cover, and that target is not going away. - The grid is stable, funded and shared, and the suite is not where the delivery pain is. - The team has no capacity to run a coexistence window, which means a partial migration would leave two half-owned suites -- the worst of the three outcomes. ## Say it out loud The failure mode at this level is not choosing wrongly; it is choosing implicitly. A decision that is written down -- the evidence, the horizon, the trigger, the owner, the exit -- can be revisited in six months by people who were not in the room. A migration that started because someone liked the trace viewer cannot.