The QA Automation Checklist for Startups Without a QA Team
TL;DR: Every QA automation checklist you’ll find online opens with “integrate into your CI pipeline” and assumes someone on the team owns QA as a job. If you’re a solo founder or a two-person team shipping an app you built with an AI tool, most of that checklist doesn’t apply to you yet, and the parts that do apply are ordered wrong for your situation. Here’s the version built for what you actually have: an app, a URL, and no one but you to run it against.
Sixty-three percent of new C corps formed in the US in the second quarter of 2026 had a single founder, according to Stripe’s own data. If that’s you, “build a QA process” can’t mean what it means for a team of engineers with a QA hire, because that team doesn’t exist yet and might not for a long time. It has to mean something you can actually do this afternoon, by yourself, that still catches the thing that would otherwise embarrass you in front of your first hundred users.
Why the checklists you’ll find don’t fit
Search “QA automation checklist for startups” and the results split into two camps, and neither one is talking to you.
The first camp is written for a startup that already has engineers. Step one is usually “integrate testing into your CI/CD pipeline,” step two is “assign clear QA ownership,” step three references your Jira board. Every item assumes a repo, a pull request workflow, and a person whose job includes reading a failed build log. If your app came out of an AI builder and your “deploys” are prompts, there’s no pipeline to integrate into and no pull request to gate.
The second camp is competitor content dressed up as advice, and it’s worth knowing what it actually says so you’re not comparing yourself to a plan that was never written for you. One popular guide walks through a seven-day setup: three days of CI plumbing and test account provisioning, then AI agents crawling your codebase to generate tests, expanding to broad coverage over the following two weeks. Useful if you have a codebase for an agent to crawl. If your app lives on a Lovable or Bolt subdomain and the only “repo” is the AI builder’s internal history, step one already doesn’t apply to you.
Neither camp is wrong, exactly. They’re just answering a different question than the one you’re asking. You don’t need a checklist for adopting QA automation inside an existing engineering org. You need one for building a QA habit from zero, alone, without infrastructure that doesn’t exist yet.
The actual checklist
This is ordered by what breaks first, not by what looks thorough on a slide.
1. Write your flows as sentences, not tickets. Before you automate anything, write down the three to five things in your app that would genuinely hurt if they broke: a new user can sign up, a returning user can log in, the thing your app is actually for works end to end. Write each one the way you’d explain it to a friend covering for you for a day, not as a formal test case. “Sign up with a new email, confirm it, land on a dashboard that isn’t blank.” That sentence is the whole spec. We went deeper on why this beats a script in how to do regression testing without a QA engineer, but the short version is that a sentence doesn’t rot the way a CSS selector does when your AI builder redesigns a page.
2. Cover the path that makes you money before anything else. If you have checkout, activation, or any step where a user converts, that flow goes first on the list, always, before anything cosmetic. A broken signup form costs you a user. A broken checkout costs you revenue and trust in the same click.
3. Add the logged-out and empty-state paths, deliberately. You’ve been testing your own account, which has data in it and is already signed in half the time you open the app. Your checklist has to include a fresh account with nothing in it, because that’s the actual state most new users start from, and it’s the state AI builders test least, since it was never in the prompt that generated the feature.
4. Set a cadence tied to how often you ship, not a calendar. A checklist you run “weekly” quietly becomes a checklist you run “when I remember,” because a fixed calendar doesn’t match how founders actually work. The honest cadence is: run it after every change that touches a flow on the list. If you ship five times a day, that’s five re-runs. That sounds like a lot until you notice it’s the only cadence that actually catches the thing that broke, since it’s tied to the moment you introduced it.
5. Put failures somewhere you’ll actually look, not a tool only an engineer opens. If checking the list means opening a testing dashboard built for QA engineers, full of run history and flake rates you don’t need, you’ll stop checking it inside a week. The result has to land somewhere as plain as “this step failed, here’s why,” because you’re the only person reading it and you don’t have time to interpret a stack trace.
6. Time-box the check itself. Decide up front how long a full pass through the list is allowed to take, and if a tool or a manual pass blows past it, that’s a signal the list needs trimming, not that you need to work faster. A checklist that costs you forty minutes every time you ship a small fix is a checklist you’ll start skipping, and a skipped checklist item catches nothing.
7. Revisit the list itself when the app changes shape, not just the flows in it. A checklist item pointing at a page that got renamed or a signup flow you replaced last month isn’t neutral, it actively wastes the pass, because you’re spending time re-confirming something that no longer describes your app. This is a smaller version of a problem we ran into building WayRunner itself: early on, saved checks kept pointing at URLs that had since moved, and a run against a page that no longer exists isn’t a QA result, it’s a wasted run. That’s part of why every run starts with a quick feasibility pass against the live URL before anything else happens; a stale checklist item should fail fast and say why, not burn ten minutes wandering a page that isn’t there anymore.
8. Know the line where this stops being a checklist and starts being a hire. Keep this one on the list even though it’s not an automation step. The checklist above is right for one or two people. It stops being enough once there are multiple people shipping and no one has the full picture of what’s supposed to work, or once “what should we even be testing” becomes a harder question than “did the tests pass.” That’s a judgment call a checklist can’t make for you; we laid out that line in more detail in the cost of a QA engineer vs an AI testing tool.
What running this actually looks like week to week
The list above is deliberately boring to read, because a checklist that requires cleverness is a checklist you won’t run consistently. The part that’s hard isn’t writing it. It’s the discipline of actually re-running it every time, by hand, while you’re also trying to ship.
This is the gap WayRunner fills, and I want to be specific about the mechanism rather than vague about the value. Each item on your list becomes a saved flow: the plain-English sentence you wrote, pointed at your live URL. A planner model looks at the page and decides the next action, an executor drives a real Chromium browser to carry it out, and it screenshots after every step so a failure shows you exactly where things went sideways instead of just that they did.
Two things about how it’s built matter specifically for a checklist you’re going to reuse constantly rather than run once. Every run is capped at 40 steps and the browser-ready time limit for its plan; a checklist item that hangs or wanders is worse than one that fails cleanly, because a run that never finishes teaches you to stop trusting the tool. And when a step does fail, a separate model reads the full transcript and the screenshot and writes what went wrong in a sentence you can act on, not a step number. “Step 9 failed” tells a solo founder nothing. “The confirm button stayed disabled because the password field still showed a validation error” tells you exactly what to fix.
If any of your checklist items sit behind a login, credentials go into an encrypted vault and get typed into the browser at the moment they’re needed, so the model deciding what to click never actually sees the password.
The takeaway
The QA automation checklists written for funded startups with engineering teams aren’t wrong, they’re just not yours yet. Yours is smaller: a handful of flows written as sentences, ranked by what actually costs you money or trust if they break, re-run every time you ship rather than on a calendar, with failures landing somewhere you’ll actually read them. Write that list today, even if you run it by hand for the first week. The list is the part that takes judgment. The re-running is the part a tool should be doing for you.
If you’d rather not run that list by hand every time you ship: wayrunner.run/#signup.