We’ve been building Playwright tests for a legacy app that doesn’t follow standard conventions. The DOM is messy, form fields don’t have proper labels, and authentication involves multiple redirects and token validation. Basically, it’s the kind of app where pre-built templates usually don’t fit.
I grabbed a couple of ready-to-use Playwright templates from various sources expecting them to at least give me a foundation to build on. Instead, I spent more time ripping out template code and rewriting it than I would have spent starting from scratch.
But I’m curious whether this is just my experience or a broader pattern. Are pre-built templates actually useful if your workflow doesn’t match the happy path they were designed for? Or do they only work well if you’re building the same tests everyone else is building?
Templates are useful, but the key is understanding what they’re for. Generic pre-built templates are designed for common scenarios. Your legacy app with non-standard DOM definitely isn’t that.
What actually works better is having templates that are intelligent and customizable. Ready-to-use templates from Latenode are adaptive—they’re not rigid structures you force your tests into. You start with a template structure, but the underlying logic adjusts to your specific app layout instead of assuming standard conventions.
The real time savings come from eliminating boilerplate. You don’t have to set up project structure, best practices for waits, error handling patterns, or reporting. Those parts are handled. What you do customize is the business logic—your specific selectors, your specific flows, your specific assertions.
For legacy apps, this approach works better because you spend less time fighting template constraints and more time building what you actually need.
I’ve been in the exact same situation. Generic pre-built templates don’t save time on legacy apps because you end up customizing so heavily that the template becomes irrelevant.
What I found actually useful was templates that focus on structure and patterns, not on specific test scenarios. Like, a template that shows you the best way to organize your test files, how to handle waits and retries, best practices for selectors. That scaffolding saves time because you’re not rebuilding architectural decisions.
For your actual test logic though, you’re going to write it anyway. The template accelerates you past the “how do I organize this” phase into the “now I write my tests” phase.
The templates that work best are ones where customization is the expected path, not an afterthought. If a template assumes your app structure matches its assumptions, you’re fighting it. If it’s designed knowing you’ll modify it, that’s when they actually help.
Pre-built templates help most when you’re building standard tests for standard apps. For non-standard scenarios like yours, the value proposition breaks down. You’re right that you often spend more time adapting than building from scratch.
What actually matters is whether the template covers infrastructure concerns—test runners, reporting, CI/CD integration, best practices for organizing test files. Those parts are useful and save time because they’re not app-specific.
But test logic for a legacy app? You almost always write that yourself because your app’s quirks are too specific. A template can’t account for unusual authentication flows or non-standard form structure.
I’d recommend cherry-picking from templates rather than adopting them wholesale. Take the project structure and infrastructure setup. Write your test logic from scratch since that’s where your non-standard requirements live.
The utility of pre-built templates correlates strongly with how closely your testing requirements match the template’s design assumptions. For standard scenarios on well-structured modern apps, templates provide substantial time savings—they handle project setup, best practice defaults, common patterns. For non-standard scenarios on legacy systems, misalignment becomes costly.
The issue with most templates is that they bundle test logic with infrastructure. Your legacy app doesn’t need custom test logic from a template—it needs you to write logic. But it does benefit from template infrastructure: test runners, report generation, CI/CD hooks, test file organization.
A better approach for non-standard work is splitting concerns: use template structure for infrastructure concerns, write your test logic from scratch for domain-specific logic. This gives you time savings where they matter (setup, configuration, best practices) without forcing bad decisions about your actual test code.
The effort to adapt a template’s test logic often exceeds time to write logic from scratch, especially for legacy/unusual codebases. The infrastructure layer, though—that’s where templates actually accelerate you.