Teams without QA still test. An engineer clicks through staging before a release, a designer notices a broken page, a founder tries signup after a big change. What's usually missing isn't care. It's a written agreement about what has to work and who looks when it doesn't.
Use the checklist as a shared agreement
Agree the few journeys that must work for a release, and pair each with a specific result. A clear item names the action and what must be true afterward. That lets a developer, designer and product owner review the same test without reading a framework's source code.
Without that, "passes QA" means whatever the person doing the release thinks it means. Revisit the list as customer behavior and requirements change.
Name two owners
Test data needs an owner, because fixtures need upkeep whether or not anyone is assigned to them. Failures need a reviewer, which could be whoever is on release duty that week. Informal ownership makes failures easy to ignore, so settle this before you add a merge gate. A gate on a suite nobody investigates teaches people to work around it.
Automate what repeats, and keep judgment visible
Not everything on the list should become a test. A test can be technically valid and still have nothing to do with a customer outcome, and not every manual observation deserves an automated assertion.
If an item can't be automated yet, that's useful information. Supply the missing test data or expectation, or keep the item manual. Don't weaken the requirement just to automate it.
Where Zerocheck fits
I built Zerocheck for the repeatable part of this. Save reviewed tests in the web app, run selected flows before a release, and use the screenshots to review failures. Anyone with access to your instance can edit web tests; there are no separate roles. When the team is ready to own a gate, add CLI runs to a CI job.