Nine years, seven companies.

Mobile is four environments wearing one costume. An emulator, a physical phone and a farm device fail in different ways at different speeds, and a suite that is only green on one of them is not a suite. Getting the console log into the report is the difference between "the checkout test failed" and "the checkout test failed because the token refresh 401'd", and only one of those gets fixed the same day.

Parallelism is where a test suite goes flaky, and shared driver state is usually why. Giving each thread its own driver through ThreadLocal fixes the mechanism, but the discipline is keeping every fixture, every wait and every piece of test data thread-safe afterwards, forever, including in code written by people who were not in the room when you chose the pattern. A flaky suite trains a team to ignore red, and once that happens the suite has negative value.

From scratch means every decision is yours, and the ones you skip become the thing the team works around for the next two years. Where a test finds its data. What a failure prints. Who is allowed to run the suite and against which environment. Where the report lands so that somebody reads it. There was no platform team to hand the pipeline to either, so the framework and the infrastructure it ran on were one piece of work.

Two years on one framework is mostly maintenance, and maintenance is harder than the build. The application changes underneath you, the team turns over, and the suite either absorbs that or rots. Being the reference point is the other half: the framework is only as good as the worst test anyone is allowed to merge into it, which makes code review part of the architecture rather than a chore next to it.

Learning that the test is not the interesting part. Keeping the page structure out of the test is what lets the test survive a redesign, and writing the test before the code is what stops you from writing a test that only asserts what the code already does. I have used both since, everywhere.