QA for a startup that has no QA engineer

In a small team the person who wrote the change is usually the one who tests it, by clicking through the preview when there is time. The end-to-end suite someone started in the first month has not been touched since the redesign.

Nobody decided to stop testing. It is nobody's job, so it happens last and least.

1. Write one test. Sign up free (3 runs, no card), give it your URL and a sentence such as "sign up, then create a project". You get a verdict, checks, findings and a screenshot of every step.
2. Connect the GitHub App. Every pull request gets a run against its preview deployment, a URL pattern, a fixed URL or the project URL, and a comment with the verdict, findings and screenshots.
3. Make the ZeusQA check required. A failing run fails the check, unless all it found is below the severity the repository blocks at. Mark it required in branch protection and the merge waits until the flow works.
4. Schedule what makes money. On Pro, rerun sign-up and checkout hourly, daily, on weekdays or weekly, and get an email when a schedule starts failing.

Open the home page and follow the main call to action to sign-up. Check that an empty submit is refused with a clear message, then open the pricing page and check that every plan's button leads somewhere that works. Report anything broken, and check computer.diagnostics() for console errors and failed requests.

Save it as the repository's prompt and every pull request runs it. Start with the one flow that would hurt most if it broke on a Friday.

You already describe the change when you open a pull request. ZeusQA gives the title and description to the agent as the claims to check, so the run tests what this change says it does, not only the flow you saved.

List what should be true under a heading such as Acceptance criteria, Test plan or How to test, up to 10 items, and each comes back met, not met or not checked. One not met fails the run, and the check with it. Pull requests from forks are left out.

Every finding has a Fix with agent menu. Copy a prompt with the page, what the tester did, what it expected and what it saw, and the evidence, or open it straight in Cursor or Claude Code.

• Free: 3 runs in total, 1 project, one run at a time, up to 30 steps a run. Enough to see a real report on your own app.
• Pro, $39 a month: 300 runs a month, unlimited projects, 3 runs at once, up to 60 steps a run, 10 schedules and optional session video. One member.
• Team, $149 a month: 1,500 runs a month shared by everyone you invite, 5 at once and 50 schedules.

• A verdict: pass, fail or blocked.
• Named checks, each marked passed or not, so you can see what was actually asserted.
• Findings rated critical, high, medium, low or info, with the evidence behind each one.
• A screenshot for every step, plus a session video on Pro and Team when you turn recording on.
• Console errors, uncaught page errors and failed or 4xx/5xx requests, collected automatically.
• Passive security findings from the responses the run loaded: headers, cookies, mixed content, open redirects, source maps, leaked secrets and stack traces.

Worth knowing before you point it at something important.

• Pro is one member. A second person with their own login needs Team.
• Schedules run at most hourly, and only on Pro and Team.
• Run alerts are email only. Slack and Discord webhooks carry vulnerability advisories, not run results.
• No CLI. Runs start from the app, the GitHub App or a schedule.
• GitHub only. GitLab and Bitbucket pull requests do not start runs.
• Runs act on the real site. Point pull request runs at preview deployments when a test creates data.