Home / Services
Playwright testing services, by the suite you have today
Most teams arrive knowing which engagement they want and we start there; the audit is for when you would rather find out first.
Firm86 works in Playwright and nothing else. The engagements below cover a suite built from scratch, a suite moved onto Playwright from whatever runs it today, a suite made trustworthy again, the pipeline that runs it, an engineer who joins your team, and teaching your own engineers to keep what they have. Engineers are billed hourly, from $50 an hour, minimum one full-time engineer for one month. Training and the audit are bought by the hour instead, with no month attached, and each page states its own terms.
Start with the suite you have
Playwright test automation
No end-to-end tests at all, and a release on Thursday nobody is comfortable shipping.
Migration to Playwright
A suite in something else, and that something else has no card of its own here.
Selenium to Playwright migration
A Selenium suite that is slow, fails at random, and sits on a Grid nobody wants.
Cypress to Playwright migration
A Cypress suite that has outgrown one browser, one tab or one origin.
CI/CD integration
The suite runs on somebody's laptop, or runs in the pipeline and changes nothing.
Flaky suite repair
The team re-runs the build instead of reading it.
Playwright framework development
Your engineers will write the tests, and the foundation under them is not there.
Playwright API testing
The HTTP layer is missing, or test state gets set up by clicking through the product.
Dedicated Playwright engineers
You know what the work is. You need somebody who already knows the framework.
Leaving Protractor
The framework was deprecated under you, and the Angular-specific waiting has nowhere to go.
Suite audit
You cannot say what the suite covers, what it misses, or what a run costs.
Visual regression testing
Nobody notices when the page changes shape, and the first report comes from a customer.
Accessibility testing
Accessibility is checked by hand before a release, if anybody remembers, and nothing in CI catches a regression.
Component testing
A broken component turns up twenty minutes into an end-to-end run, or not at all.
Training
Your engineers have to keep the suite after we leave, and nobody has sat with them over their own code.
When two of these look like the same job
The deciding question is whether the old suite was ever trusted. If the tests were believed and the framework is what hurts, a migration moves them across. If nobody had read a red build in a year, the migration page calls that a deletion, and the thing to buy is a suite from scratch.
A red build has two causes and they are two engagements. Specs that fail at random on a commit that has not changed are flaky suite repair. A build that goes red for a reason and merges anyway is a pipeline nobody wired to a consequence, which is CI/CD integration.
Who writes the specs once we leave? If your own engineers do, what is missing is the foundation under them — config, fixtures, the sign-in, the conventions — and that is framework development, whose first question works through the handover. If we write the specs too, it is test automation. If the foundation is already there and the team is the part that has not caught up, that is training: an engineer of ours goes through the suite you already own with your team, and it is bought by the hour with no month attached.
Does the work have a scope or a backlog? A scope has an end: we plan it, run it and hand it over, and every other line here works that way. A backlog your own people reprioritise every sprint wants a dedicated engineer, directed by your team and sitting in your standup.
If none of the questions above has an answer yet, start with the suite audit. An engineer who works in Playwright reads your test suite and the pipeline that runs it, and writes up what they find as a report you keep.
Four of the pages above are layers rather than engagements: visual regression, API testing, component testing and accessibility testing. Each one goes inside a suite, so the question is whether there is a suite for the layer to sit in. If there is not, the layer arrives as part of the build and you are buying the build.
What is true of all of them
Every engineer here works in Playwright, and there is no Selenium practice down the corridor to hand you to. That is the reason to hire us and also the limit on it: where the answer is another framework, we say so.
We deliver in all four official bindings — TypeScript or JavaScript, Python, Java and .NET. A Java team gets a Java suite and can still read it a year from now. What is not true of all four is every deliverable on this page: Playwright's own test runner ships only with the JavaScript and TypeScript binding, so an engagement built on a runner feature says on its own page which bindings it covers. Tell us the binding first and we will say what we would propose in it.
The work lands in your repository, on branches, through pull requests your own reviewers approve. There is no separate deliverable to import at the end.
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. Two engagements are the exception — the audit and training — and both are bought by the hour, on their own, with no month of anybody's time attached. Training is also the one thing here that is not priced by the engineer, so its rate is on its own page rather than in this paragraph.
What none of them include
- Native mobile apps. Playwright drives browsers. It emulates a phone — viewport, user agent, touch input — which covers a responsive web app at phone size and is not the app your users installed from a store.
- Load and performance at scale. No engagement here is a load test. Playwright watches one browser closely; k6, JMeter and Gatling answer the other question.
- Security and penetration testing. Not offered, in any framework.
- Safari on a real iPhone. Playwright's WebKit build renders close to Safari and is not Safari on a device.
The pros and cons of Playwright is the long form of that list.
Questions
We do not know which of these we need. Where do we start?
Start from the symptom. The second line of every card above is written as one, so find the line that describes your repository this week and follow it. Where two of them fit, the section under the cards names the question that separates the pair.
Can we buy more than one of these, or one after another?
Nothing here is exclusive of anything else, and several are written as each other's next step: a migration ends with a suite that CI/CD integration then wires into the pipeline. What has not been settled is how the one-month minimum counts across a second engagement.
What is the smallest engagement you take?
One full-time engineer for one month, on every engagement above except two. The audit and training are both bought by the hour, on their own, with no month of anybody's time attached, and training is billed at its own rate, which its page states. What the month costs depends on where the engineer sits, and engineers are billed hourly, from $50 an hour.
Do any of these cover our native mobile app, load testing or a security review?
No, to all three. Playwright drives browsers, so the closest any engagement here gets to your native app is your web build at a phone-sized viewport. Load and performance testing needs a different tool and we do not sell it. Security and penetration testing is not offered in any framework.
We have not settled on Playwright yet. Is any of this for us?
Probably not yet, and we are a poor referee for that decision: we work in one framework and would be arguing our own side of it. Read what Playwright is first, and the comparisons with Selenium, Cypress and WebdriverIO that sit beside it. Come back when the decision is made.
Not sure which one?
Send the repository, or a week of CI runs, or a paragraph on what the suite does today and what that costs you. Somebody who works in Playwright reads it and writes back. If you already know which engagement you want, say that instead and we will scope it.