Playwright & Selenium
Browser automation at scale — for data collection and for the portals with no API.
Playwright is our default for browser automation and Selenium remains in use where an existing estate or a specific legacy requirement calls for it. The work splits two ways: large-scale data collection from public sources, and automating internal workflows on portals that offer no API and never will.
The second category is under-appreciated and often more valuable. A government filing portal, a bank statement download, a supplier system your staff log into forty times a day — the browser is the only interface, and automating it removes hours of repetitive work without needing any cooperation from the system's owner.
What separates a working prototype from a system that runs for years is monitoring. Every automation breaks eventually because websites change; the question is only whether you find out within the hour or after three weeks of silently empty results.
Where it fits
What Playwright & Selenium genuinely gives us
Auto-waiting that removes flakiness
Playwright waits for elements to be actionable rather than requiring arbitrary sleeps, which eliminates the largest source of intermittent failure.
Genuine browser context isolation
Independent sessions in one browser instance, which makes concurrency cheap in memory terms.
Network interception
Requests can be inspected, blocked or modified, so images and trackers need not be downloaded at all.
Excellent debugging tooling
Trace viewer with screenshots, DOM snapshots and network log for every step makes a failure diagnosable rather than mysterious.
Making a failing test worth reading
A test suite earns trust through the quality of its failures. A failure that says an element was not found, with no screenshot, no trace and no indication of what the page actually looked like, teaches the team that investigating failures is expensive — and a team that believes that will start rerunning the pipeline instead of reading the output.
So we configure the diagnostic layer before we write coverage. Traces captured on failure so the run can be replayed step by step. Screenshots and the DOM snapshot at the point of failure. Console and network logs attached. Test names that describe the user-facing behaviour rather than the mechanics, so a failure in a summary report is meaningful to someone who did not write the test.
Flakiness is treated as a defect with an owner rather than as background noise. A test that fails intermittently is quarantined immediately so it stops eroding confidence in the suite, and then fixed properly — which almost always means replacing a timing assumption with a real wait condition, or removing a dependency on data another test created. Suites that tolerate a handful of known-flaky tests reliably degrade into suites nobody reads.
Test automation that survives contact with a changing product
Most automated test suites we inherit are abandoned. They were written enthusiastically, they became slow and flaky, the team started ignoring failures because failures were usually the test’s fault rather than the product’s, and eventually somebody switched them off in the pipeline. The cause is almost never the tool. It is that the suite was written against the wrong things: selectors tied to CSS classes that designers legitimately change, fixed waits standing in for real synchronisation, and tests that depend on data another test created.
The practices that produce a suite people trust are well established. Select elements by role, label or explicit test identifier, so a visual redesign does not break a hundred tests. Never sleep — wait for the condition that actually matters. Make every test create and clean up its own data so tests can run in any order and in parallel. Keep the pyramid honest: a small number of end-to-end journeys covering the paths that carry money, a larger layer of integration tests, and unit tests for logic. Teams that try to test everything end-to-end end up testing nothing reliably.
For a business in this market the highest-value application is usually narrow and specific: the checkout, the enquiry form, the login, and the two or three flows whose failure would cost real money before anyone noticed. Automating those and running them against production on a schedule catches the outages that matter, which is worth considerably more than broad coverage of pages nobody uses.
Strict parsing that fails loudly
The failure mode that destroys a dataset is not a crash — it is a scraper that keeps running, keeps reporting success, and quietly returns nulls for three weeks after a layout change. So every field has an expected type and a validation rule, and a page yielding a null where a value is expected raises a parse failure rather than storing a blank.
On top of that we monitor per-field fill rates against a historical baseline. A price field dropping from 99% populated to 40% triggers an alert within the hour, long before anyone notices a gap in a report.
Scale and politeness together
We run up to 240 concurrent browser sessions in Kubernetes, but concurrency is bounded per target domain rather than by our capacity. Delay and parallelism are tuned to the target's size and observed response behaviour, with automatic backoff when latency rises or errors increase.
Plain HTTP requests are always preferred where they work, because a browser is roughly an order of magnitude more expensive per page. We use a browser only where JavaScript rendering genuinely requires it.
How Playwright & Selenium projects usually go wrong
These are the failure modes we look for first when we are called in to rescue somebody else's implementation.
Playwright & Selenium questions we get asked
Including where we would recommend something other than Playwright & Selenium. Call +91 70033 91355 and you will get the same answer from an engineer.
Playwright for new work — auto-waiting, better debugging, faster execution and a cleaner API. Selenium where a large existing test estate makes migration uneconomic, or where a specific legacy browser or grid infrastructure is required. We maintain both and will not push a migration that does not pay for itself.
Monitoring detects it, usually within the hour, through fill-rate anomalies rather than waiting for a crash. Median repair is under two hours in working hours and is covered by maintenance agreements. Because we retain raw HTML, the repaired parser can be applied retroactively to the broken window, so in most cases there is no permanent gap in the data.
With your credentials and your right to access, yes — your own supplier portals, marketplace seller accounts or subscriptions your company legitimately holds. We will not bypass authentication we have no right to, defeat paywalls, or use credentials the client is not entitled to share. Where a subscription's terms prohibit automated access we tell you rather than proceed quietly.
Services built on Playwright & Selenium
Technologies we pair it with
Tell us what is slowing your business down.
A 30-minute call with a senior engineer — not a salesperson. You leave with an architecture sketch and an honest cost range, whether or not you hire us.
Direct line
+91 70033 91355Mon–Sat · 9:30 AM – 7:30 PM IST · Sealdah, Kolkata