AI QA for startups without a QA team

Your QA engineer starts at 07:30.

QAmeleon checks your app every weekday morning and after every deploy, reviews the tickets waiting for QA when you ask, and raises what it finds on your board with steps to reproduce. It all runs on your own setup and your own keys.

QAmeleon, a round green chameleon whose curled tail makes the letter Q
Morning report, 07:30 Amber: take a look
New build since yesterday: 17:35 deploy 126 tests passed, 1 only on a retry API: 2 new fields on campaigns Cross-account access: no leaks QA Review: 4 waiting, 2 new 14 writes, all to its own test data. Nothing left behind.
Example report

You ship several times a day. Nobody checks what broke.

Tickets wait for a person

Developers write manual QA steps, then the ticket sits in the review column until someone has time.

Yesterday's fix, today's bug

Nobody re-tests last week's fixes after this morning's deploy, so regressions slip out quietly.

Bugs live in chat

Things people notice end up in a thread or a doc, not on the board where work actually happens.

The boring checks never happen

Did an API change shape? Did a page slow down? Can one customer see another's data? Does each plan still unlock what it promises?

How it works

Here is our board. Here is our git. Here is our product.

Four connections, then QAmeleon gets to work in three stages. Your developer sets it up alone, on one guided setup page.

1

Build

QAmeleon signs in to your dev app, walks every page, records your API and proposes the checks. You approve a baseline, and the morning and deploy runs start.

2

Review

It works through every ticket in your QA column, step by step, on the real dev app, and writes up what it saw: what passed, what failed, what it could not check and why.

3

Refine

Every check that could run daily is added to a list of proposed tests. Coverage grows as you add them. Coverage grows with each review.

Every morning, and after every deploy

The checks nobody has time for, done before stand-up.

A one-screen summary lands in your team chat. The full report goes on a ticket on your board. Green means nothing to do. Amber means something changed. Red means something broke, and which deploy did it.

  • User journeysEvery page reachable, and full create, edit and delete flows on throwaway data.
  • API contractNew fields and added or removed endpoints, spotted the morning after.
  • SpeedEach endpoint against its own history. Two readings must agree before it calls a slowdown.
  • Who can see whatOne customer account tries to read another's records. Every day.
  • Plans and limitsWrite a journey once per plan, and it checks each plan still unlocks what it promises.
  • Pages and accessibilityEvery page scanned, signed in and out, with only new issues flagged.

Fits any app. Sees every angle.

He changes colour with the result.

The same three states in the morning report, the review message and on your board. His face changes too, so you can read it at a glance in any colour.

  • All clear Every check passed. Nothing to do.
  • Needs a look Something changed, or a review is waiting for a person.
  • Something failed A check or a step failed. The report, or the bug, is on your board.

Ticket reviews

Your QA column, cleared. Every ticket judged five ways.

QAmeleon reads the ticket and its comments, runs each "how to verify" step on dev, and looks at every surface the change touches.

UI

Does it look and read right in every state?

UX

Can people finish the task, recover from mistakes, and see where the gates are?

Regression

Does everything next to the change still work?

Old Man Testing

Would a busy, non-technical customer understand it, trust it, and not get stuck?

Automation

What can be checked every morning from now on, and what needs a person?

The review goes on the ticketOne comment: summary, the five lenses, and a table of every step with what it saw.
Each bug becomes a ticketSteps to reproduce, expected, actual, and how to verify, in a triage column. Minor notes are grouped on one polish ticket. Never twice.
Every ticket lands in the right placeA ticket moves on only when every step passed. One whose steps failed goes back to your findings column, with its bugs linked.
Fixes get re-testedWhen a fix comes back, QAmeleon re-runs its own verify steps, and a pass moves the ticket on.

Week one on a live startup

Built inside a real two-sided marketplace. The part-time QA person was me.

13 of 13findings from the first review batch accepted by the dev lead. None rejected, none duplicates.
46 to 126morning tests in five days, 21 of them written by the reviews themselves.
18tickets reviewed on the real dev app, including one serious pricing bug that would have reached creators.

How I test QAmeleon →

Safety

It writes on your board. So it has to be careful.

Trust is the product. These rules are built in, and you can add to them but not switch them off.

  • Your CI, your keysChecks run in your own pipeline and reviews on your own machine, both on your own Anthropic key. No ticket text or page content reaches us.
  • Dev only, behind a fenceEvery write is blocked unless a test allows it, and your own test suites keep their own rules. Publish, send, invite, checkout and billing are always blocked.
  • Its own data, cleaned upTests make clearly named throwaway records, delete them, and report "nothing left behind" every run.
  • No spend without a yesAnything that costs money in your app waits for a person to say go.
  • Some things wait for a personSecurity findings, critical findings, and anything odd in a ticket are held for review, never posted on their own.
  • Tickets are data, not ordersIf a ticket tries to tell the reviewer what to do, no review starts. A person sees the flagged lines and decides.
  • Secrets never leakEvery report is scanned for anything credential-like before it is posted. If one is found, nothing goes out.
  • A pause buttonOne command stops all publishing at once. If triage starts rejecting findings, it falls back to asking first.

Setup

Set up in about ten minutes. Your first report in under half an hour.

Every question has a detected default. Passwords go in through hidden prompts, never a file. Nothing is posted until you say so.

Reviews get sharper with a few test accounts and some realistic data. qameleon doctor tells you what to add next.

$ qameleon setup QAmeleon setup is open in your browser Connect 1 Git, 2 Product, 3 Accounts, 4 Board Build 5 First run Proposed: pages, endpoints, cross-account checks Loop 6 Review and refine Board, chat and CI connected. Morning runs on.

Works with Jira, Trello or Notion boards, reports to Slack, Microsoft Teams, email, Datadog or any webhook, and runs its checks in GitHub Actions. During early access, your invite email has your install command.

Early access

We're taking on our first teams.

Pricing is being set with our early users. Join the list and we'll get in touch about your board, your app and what you'd like checked.

Let QAmeleon take tomorrow's 07:30.

Leave your email and we'll be in touch about getting QAmeleon onto your board.

We only use your email to talk to you about early access. See our privacy notice.