Product Checks After Every Merge
When a PR lands, an agent opens the product, checks that the affected flows still work, and reports what it found.
Tests Pass, and the Product Still Breaks
Unit and integration tests cover what someone thought to test. A merged change can still break a page, a flow, or a link that no test touches, and the team finds out from a user. Checking the product by hand after every merge doesn't scale.
An Agent Uses the Product the Way a Person Would
A pull request or deployment event starts an agent. It uses Felan's managed browser to explore the live application, runs the relevant test selection, and classifies anything that fails as a product, test, or environment issue. The result comes back as a report for the team to review.
- Sign-in and checkout flows
- Settings page loads
- Invoice download returns 404
Common Questions
What triggers a check?
A pull request or push event from GitHub, a merge request event from GitLab, or a deployment event from Vercel. You can also run checks on a schedule.
Does it need our existing tests?
No, but it can use them. The agent explores the application in a managed browser, and can also run your repository's Playwright tests.
Where do the findings go?
Into the session, visible to the whole team. With a supported issue tracker connected, it can prepare findings for that tracker.
Which models can it use?
Any major provider, plus local and private models. Bring your own keys or subscription, and there's no markup on tokens.
Related: Quality assurance docs, Failed build triage.
Keep Your Attention for the Hard Problems
Start with one repo and one recurring task.