Should we automate everything?

No, and a page that says otherwise is selling you maintenance you will resent. A case that runs twice a year costs more to keep working than to click through by hand. Anything needing a human eye — whether a photo looks right, whether a layout reads well — cannot be automated honestly. Before we write a line of code you get a list of your manual cases marked automate, do not automate, or later, each with a one-line reason. Expect real entries in the do-not column.

What happens when our site changes and the tests break?

That is the whole question, and it is why every build here is sold with a maintenance arrangement attached. The structure helps — page objects keep each screen's selectors in one file, so a renamed button is one edit rather than one hunt through every test that touches it. But no structure survives a redesign untouched. A suite with nobody responsible for it does not decay slowly — it gets switched off to unblock a release, and is never turned back on.

Can you automate our login if it sends a one-time code?

Only if a test bypass exists or can be built. This is the single most common thing that changes a quote, because without it every test that needs a logged-in user is blocked. Sometimes that bypass has to be built with your developers before a single test can be written, and we would rather say so in the first call than discover it in week three.

Will the suite run in our CI?

Yes, and that is the point — a suite that only runs on somebody's laptop is a hobby. We wire it into your pipeline with retries enabled on CI and disabled locally, a trace captured on first retry, and the HTML report stored as a build artifact so a failure can be inspected after the fact rather than reproduced by hand.

How do we know the tests are actually checking something?

Because you can read them. A very common failure is a test that performs every step and asserts nothing — it passes forever and catches nothing. Every test we write carries at least one real assertion about the outcome, not merely that a page loaded, and computed values such as a total including tax are checked as numbers rather than checked for existence.

QA, Support & Ongoing Operations

Automated test suites that do not get switched off

Playwright or Cypress coverage of the routes that actually matter, wired into your pipeline, with a maintenance arrangement so it is still running next year.

From: $1,500–$20,000
Typical time: 3–10 weeks
Usually bought by: Dev teams

What this actually solves

Manual regression is a cost that grows quietly and never stops. Every fixed bug becomes a case you must re-run forever, so the pack only ever gets longer, and you pay for the whole of it again on every single release. Do the arithmetic with your own numbers: the length of your pack by hand, multiplied by how often you deploy, is a bill that arrives every month for as long as the product exists, and all it buys is the news that things which already passed still pass. The same pack in code runs unattended, at night, on a public holiday, without getting bored and skipping the dull ones near the end.

The second effect is the one teams actually feel. Groups with a working suite deploy often and calmly. Groups without one deploy rarely and nervously, batch up changes because each release is frightening, and then have a harder time diagnosing failures because ten things shipped at once. The suite is not really about finding bugs — your manual testing finds more. It is about making it cheap to be sure nothing that used to work has stopped working.

This is also the service where AI can write the code and still supply none of the value. Generating a page object and a spec file is well-suited to a model. Knowing which routes are worth automating, how test data gets created and cleaned in your specific environment, and which of your business rules would silently produce a wrong number is not, because none of that is in the code it is reading.

How the work runs

Read the manual pack and decide what not to automate. We go through your existing cases and pick the fifteen to twenty-five routes that earn automation — the money path, login and accounts, and the cases created by bugs that have already happened once. You get that decision as a list with reasons before any code exists. Two to four days.
Environments and test data. Consistently the largest and most underestimated part. Where does the suite run, does staging reset overnight, is there a login bypass, and how does each test create the data it needs and clean it up afterwards so two tests running in parallel do not corrupt each other. Getting this wrong is what makes a suite unstable once it has been running a while. Three days to two weeks.
Framework and structure. Config, fixtures, and a page object per screen so every selector lives in exactly one file. Selectors are chosen by role, label, placeholder, text or a dedicated test attribute. Long CSS descendant chains and XPath are not used — they break on the next design change and produce failures that look like bugs. Three to five days.
Tests written in batches, shown as they land. Each batch goes to your team to review rather than arriving as one large delivery at the end. Every test asserts a real outcome. No hard sleeps anywhere in the suite. One to four weeks depending on the number of flows.
Killing flakiness before handover. The suite is run repeatedly — five times as a minimum — and anything that changes result without the code changing is treated as a defect in the suite and fixed. The cause is usually in your system rather than the test code, and naming it correctly matters — a slow API, an aggressive cache, one shared test account being used by two tests at once. Three to five days.
CI wiring and handover. Runs on every pull request, retries on CI only, trace on first retry, report kept as an artifact. Handover is a README, a recorded walkthrough, and an agreed maintenance arrangement for the following three months. Two to four days.

What moves the price

The range is $1,500–$20,000 over 3–10 weeks, and the spread is genuinely that wide because these are not the same job.

How many flows, and whether the API is included. Testing through the browser only is one scope. Testing the API underneath it as well is another, and it is usually the better buy when a mobile app and a website share the same backend, because one suite then covers both.

Whether your system can be automated at all. A login that sends a one-time code with no test bypass, a payment step that cannot be completed without a real card, a staging environment that does not match production — each of these turns part of the engagement into enabling work before a single test can be written.

Who wires it into the pipeline. If your team owns CI and wants to plug the suite in themselves, that is cheaper. If we are configuring the workflow, secrets, artifacts and reporting, that is real work and it is a separate line in the quote.

What usually goes wrong

Everything gets automated. It sounds thorough, and it is how a suite becomes a liability. Every automated test is a permanent maintenance obligation, so a case that runs twice a year now costs more to keep alive than it ever cost to click through. The suites that survive are deliberately narrow — the revenue path, the login path, and the routes that have already broken once.

Hard sleeps get used to hide instability. A test fails intermittently, someone inserts a fixed wait, the failure stops, everyone moves on. It has not stopped — it has been made slower and less honest, and it will resurface as a suite that takes longer every month and fails randomly on release day. The fix is a proper wait on the condition, or finding the real cause in the application.

The suite is handed over with nobody responsible for it. This is the one that wastes the whole budget. The site changes, a wall of tests goes red, nobody has time to work out which failures are real, the team switches the suite off in CI to unblock a release, and it is never turned back on. What decides that outcome is whether anyone is named and paid to keep the suite green, not how well it was written.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Should we automate everything?: No, and a page that says otherwise is selling you maintenance you will resent. A case that runs twice a year costs more to keep working than to click through by hand. Anything needing a human eye — whether a photo looks right, whether a layout reads well — cannot be automated honestly. Before we write a line of code you get a list of your manual cases marked automate, do not automate, or later, each with a one-line reason. Expect real entries in the do-not column.
Playwright or Cypress?: Playwright for anything new. It drives a real browser from outside, waits for elements on its own, runs Chromium, Firefox and WebKit from one config, and saves a trace of the failed run. Cypress is only the right answer when you already have a working Cypress suite, in which case rewriting it is spending money to stand still.
What happens when our site changes and the tests break?: That is the whole question, and it is why every build here is sold with a maintenance arrangement attached. The structure helps — page objects keep each screen's selectors in one file, so a renamed button is one edit rather than one hunt through every test that touches it. But no structure survives a redesign untouched. A suite with nobody responsible for it does not decay slowly — it gets switched off to unblock a release, and is never turned back on.
Can you automate our login if it sends a one-time code?: Only if a test bypass exists or can be built. This is the single most common thing that changes a quote, because without it every test that needs a logged-in user is blocked. Sometimes that bypass has to be built with your developers before a single test can be written, and we would rather say so in the first call than discover it in week three.
Will the suite run in our CI?: Yes, and that is the point — a suite that only runs on somebody's laptop is a hobby. We wire it into your pipeline with retries enabled on CI and disabled locally, a trace captured on first retry, and the HTML report stored as a build artifact so a failure can be inspected after the fact rather than reproduced by hand.
How do we know the tests are actually checking something?: Because you can read them. A very common failure is a test that performs every step and asserts nothing — it passes forever and catches nothing. Every test we write carries at least one real assertion about the outcome, not merely that a page loaded, and computed values such as a total including tax are checked as numbers rather than checked for existence.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Test automation All QA, Support & Ongoing Operations services