Hire dedicated Playwright engineers from a company that does nothing else

What a specialist writes in week one

Below is what an engineer writes, beside what the same decision looks like in a suite built by somebody who was learning the framework as they went. The second version in each pair gets written on the first morning, before there is a suite to fix.

The samples below were written against Playwright 1.62.

The login, and it is most of the bill

A test needs an authenticated page. This is the version that ends up copied into every spec file in a suite:

import { test, expect } from '@playwright/test';

test.beforeEach(async ({ page }) => {
  await page.goto('https://app.example.com/sign-in');
  await page.getByLabel('Work email').fill('rita@example.com');
  await page.getByLabel('Password').fill('correct-horse');
  await page.getByRole('button', { name: 'Log in' }).click();
  await expect(page.getByRole('heading', { name: 'Projects' })).toBeVisible();
});

test('archives a project', async ({ page }) => {
  await page.getByRole('link', { name: 'Apollo' }).click();
  await page.getByRole('button', { name: 'Archive' }).click();
  await expect(page.getByText('Project archived')).toBeVisible();
});

It works, which is why it survives. It also drives a full browser login once per test, so a four-hundred-spec suite signs in four hundred times a run and pays for it in wall-clock on every pipeline, forever.

Here is the same decision made by somebody who has unpicked this before. A setup project signs in once and writes the browser state to a file:

// tests/auth.setup.ts
import { test as setup, expect } from '@playwright/test';
import path from 'path';

const authFile = path.join(__dirname, '../playwright/.auth/user.json');

setup('authenticate', async ({ page }) => {
  await page.goto('https://app.example.com/sign-in');
  await page.getByLabel('Work email').fill('rita@example.com');
  await page.getByLabel('Password').fill('correct-horse');
  await page.getByRole('button', { name: 'Log in' }).click();
  await expect(page.getByRole('heading', { name: 'Projects' })).toBeVisible();

  await page.context().storageState({ path: authFile });
});

The config declares that the setup project runs first and that the test project starts from the state it wrote:

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'setup', testMatch: /.*\.setup\.ts/ },
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'], storageState: 'playwright/.auth/user.json' },
      dependencies: ['setup'],
    },
  ],
});

And the spec opens already signed in:

import { test, expect } from '@playwright/test';

test('archives a project', async ({ page }) => {
  await page.goto('https://app.example.com/projects');
  await page.getByRole('link', { name: 'Apollo' }).click();
  await page.getByRole('button', { name: 'Archive' }).click();
  await expect(page.getByText('Project archived')).toBeVisible();
});

Two lines in there are the ones worth hiring for. dependencies: ['setup'] is what makes the setup project run before the tests, and a half-copied version of this pattern fails exactly there — the state file is missing on the first run and the specs land on a login screen. And playwright/.auth goes into .gitignore without anybody asking, because that file holds cookies that can sign in as the test account, and Playwright's authentication documentation says plainly that it should not be committed to a repository, private or public. One shared sign-in is the right shape for a suite whose tests read more than they write; the moment tests start changing server-side state, the same engineer moves to one account per worker.

The button in the row that moved

A test has to click a control inside one row of a list. Positional selectors are what a suite collects when nobody has been burned yet:

import { test, expect } from '@playwright/test';

test('adds the second product to the cart', async ({ page }) => {
  await page.goto('https://shop.example.com/products');
  await page.locator('ul.products li:nth-child(3) button').click();
  await expect(page.getByText('1 item in cart')).toBeVisible();
});

That passes until somebody changes the default sort, adds a promoted row at the top, or wraps the button in a div. Scope by what the row is, then reach inside it:

import { test, expect } from '@playwright/test';

test('adds Product 2 to the cart', async ({ page }) => {
  await page.goto('https://shop.example.com/products');
  await page.getByRole('listitem')
      .filter({ has: page.getByRole('heading', { name: 'Product 2' }) })
      .getByRole('button', { name: 'Add to cart' })
      .click();
  await expect(page.getByText('1 item in cart')).toBeVisible();
});

The second one survives a re-order and reads like the product. Locators are also strict, so an ambiguous match throws instead of quietly clicking the first thing it found; the long version of that is its own article.

Both decisions get made in the first week and then never opened again, and the wrong version is paid for on every run for as long as the suite lives.

What it costs

An engineer on this engagement is priced the way every hour here is priced, because it is the same engineer. Engineers are billed hourly, from $50 an hour, depending on where the engineer sits. The minimum engagement is one full-time engineer for one month.

The hourly rate moves with where the engineer sits, and no per-location figure is published on this site because none has been confirmed, so the table further up is not a price list. There is no monthly total on this page either: multiplying an hourly rate by a month means assuming how many hours are in one, and that is a number nobody here has given you.