We’ve got a solid set of Playwright automations built for our main product. Now we’re spinning up a new project with similar workflows—same core user journeys, different UI, different backend. The obvious move is to grab the templates from project one and adapt them for project two.
But I’m wondering if this is actually saving us time or just creating a maintenance headache. If we copy templates across projects, we end up managing multiple versions of the same tests. When best practices change or we find a better approach to handling something like dynamic content, do we update all copies? Do they drift?
I’ve been looking at template marketplaces and reusable template systems where you can theoretically publish a template once and clone it for different projects, with each clone adapting to its target app. That sounds better in theory, but I’m not sure it works in practice.
Has anyone actually scaled this? Do you maintain a single source of truth for templates across multiple projects, or does each project just have its own copies that gradually diverge?
The template cloning problem is real, but it’s solvable with the right setup. Instead of copying and pasting static templates, think of templates as parameterized workflows.
With Latenode, I publish a template once with variables for things like app URL, selectors, browser list, and assertion values. When I clone it for a new project, I just update those variables. The core automation logic stays the same, but it adapts to the new environment. If I find a bug or improve a step, I update the source template and can propagate changes to clones.
This is where template marketplaces actually shine. You publish once, clone many times. Each clone is linked to the source, so updates flow through. You avoid the drift problem entirely.
We handle checkout automation across three different products this way. Same template, different configurations. When we optimized the assertion logic last quarter, every project automatically got the improvement.
We tried the copy-and-paste approach and learned painful lessons. Two projects, almost identical templates, and within six months they’d diverged completely. One team found a workaround for a timing issue, the other didn’t. One team updated selectors for a UI change, the other was still using old selectors.
What worked better for us was creating a shared template library with clear documentation and versioning. We still have per-project adapters, but the core test logic lives in one place. It requires some discipline—everyone has to agree on the architecture—but it prevents the chaos of multiple diverging versions.
If you’re just starting with multiple projects, establish a single template as your golden source and make cloning intentional, not accidental.
Template duplication becomes a problem at scale. We support five projects now, and maintaining separate copies of fundamental test patterns is unsustainable. What helped was separating test logic from test configuration.
The core assertions and steps are maintained in a central template. Projects customize through configuration files that specify their app URLs, selectors, and data. Changes to the core template automatically apply to all projects. Only configuration diverges.
This requires some upfront investment in template design, but prevents the branching nightmare later.