Every automation suite starts clean and ends up tangled if the architecture underneath it doesn’t scale. We’ve rebuilt enough 200-file, unmaintainable test suites to have a strong opinion on this: the pattern you choose at 50 tests determines whether the suite is still trustworthy at 3,000 tests.
Page Object Model: The Default for a Reason
Page Object Model (POM) wraps each page or component in a class that exposes locators and actions - loginPage.enterEmail(), loginPage.submit()- so tests read like user actions instead of raw selectors. It’s the right default for most suites: low ceremony, easy to onboard new engineers onto, and every major framework (Playwright, Cypress, Selenium) has first-class support and tutorials for it.
Where POM Starts to Strain
- Business workflows that span multiple pages push logic into test files or bloated “flow” helper classes.
- Reusing the same user journey across many test files leads to duplicated orchestration logic.
- Testing the same flow as different user roles (admin vs. standard user vs. API-only) multiplies page objects instead of reusing behavior.
- Suites organized purely around pages struggle to express business-readable test intent for non-engineers reviewing coverage.
Screenplay Pattern: Actors, Tasks, and Abilities
Screenplay reframes the test around who is doing something and why, not which page they’re on. An Actor (a user persona) has Abilities (browse the web, call an API) and performs Tasks (log in, submit a mortgage application) composed of smaller Interactions(click, type, select). Tests read as business scenarios - “Sandeep logs in and submits a loan application” - regardless of whether that action happens through the UI or an API call underneath.
A Concrete Comparison
In POM, testing the same “submit application” flow for three user roles typically means three near-duplicate test methods stitching together page objects in slightly different orders. In Screenplay, it’s one SubmitApplication task reused by three different Actors, each with the abilities and context appropriate to their role - the task logic is written once.
When to Choose Which
- Small to mid-size suites (under ~300 tests), single user role, page-centric app: Page Object Model.
- Large enterprise suites, multiple user roles, cross-channel flows (UI + API), long-lived suite (multi-year): Screenplay Pattern.
- Teams new to automation: start with POM - Screenplay has a real learning curve and isn’t worth the overhead until the suite’s complexity demands it.
We don’t treat this as a religious choice. We architect new enterprise suites with Page Object Model by default, and migrate the highest-value flows to Screenplay once a suite’s cross-role, cross-channel complexity starts to outgrow it - usually somewhere between 300 and 800 tests, depending on how many user personas the application supports.
Our Approach at SuperWiIT
Every Playwright automation engagement we run starts with an architecture decision, not a tooling decision - POM or Screenplay, sanity/smoke/regression tiering, and Core Web Vitals checks baked into the same pipeline. Getting that decision right up front is what keeps a 3,000-test suite as maintainable on day 900 as it was on day one.