Why I Built Qalizer: QA Automation Was Too Expensive for Indie Makers

I run more side projects than I'm comfortable admitting. Each one starts the same way: a weekend of motivated coding, a half-finished dashboard, a "launch next month" promise to myself, and absolutely zero test coverage. I'm not proud of that first part. But I am honest about it, because I think most solo makers and small teams are in the exact same boat.

The frustrating thing was that I knew what I was missing. I wanted regression coverage before a release instead of finding out from a user afterwards. And yet, the moment I sat down to set that up for my own tiny SaaS, every tool in the market seemed to say "not for you."

Note on the voice: this post is my own account of building the product. Where it describes a specific past incident, that anecdote is a hypothetical illustration written to make the problem concrete, not a claim that it happened to a named customer — anything that depends on someone else's experience needs their sign-off before it is published as fact.

This is the story of why Qalizer exists, what I built, and what I still haven't solved.

The enterprise tax

Let me walk through what happened when I tried to do QA "properly" on a side project.

First, I looked at the obvious names. The established platforms are genuinely good products. Their pricing pages, though, are written for accounts with a testing budget line. Entry plans routinely cost more per month than a small side project earns, and the features you actually need — deeper crawl coverage, API checks, the good reports — tend to sit in the tiers above it.

To be concrete about the size of the wall: I wasn't going to spend more on test tooling than the product made, and I also didn't want to commit to a monthly subscription for something I'd use in bursts — a crawl after a refactor, a regression run before a release, nothing in between.

Then I looked at the open-source route. Playwright, Cypress, Selenium — the tooling is excellent and free. But "free" hides the real cost: your time. Let me be generous to myself and say I'm a decent developer. Standing up Playwright, writing a first suite, handling selectors that break when a designer moves a button, wiring it into CI, maintaining the thing month after month — that isn't a weekend project. That's a part-time job I didn't have, and one I'd abandon the moment a feature deadline appeared.

I wanted something in the middle. Something between "enterprise contract" and "build it yourself" — something I could point at my app and trust, without adding a dedicated QA engineer to the payroll of a project that doesn't have one.

The idea that wouldn't leave me alone

The breakthrough idea was embarrassingly simple: what if the crawler found the tests for me?

Every serious QA effort starts with a list of pages to test. Someone, somewhere, maintains that list by hand — or worse, forgets to, and you only discover the untested page when its feature breaks in production. But a web app's pages are largely discoverable: a crawler can walk links, load pages and return the ones it actually reached. It won't find every route — pages behind a login wall, behind interactions the crawler never performs, or generated purely client-side can stay invisible — but the list it produces comes from the app, not from someone's memory. No human-maintained list required.

So the core loop I kept coming back to was:

1. Add your site — give me a URL.
2. Crawl — map the pages that are actually reachable, and classify what each one is (auth, form, purchase flow, simple navigation).
3. Generate — turn discovered pages into real tests, not vague "check this renders" stubs.
4. Run on a schedule or in CI — so the tests actually catch regressions, instead of sitting unused.
5. Report and alert — because a test that fails silently is worse than no test at all.

And I wanted all of this priced the way I wanted to buy things: pay for what you use, with enough signup credits to validate the whole thing before deciding to buy more. (The crawl is where I start in practice, because it decides what the tests will even be about — I wrote a whole post about that, Crawl Before You Test.)

I decided to build it.

What I actually built

Qalizer became a real product, not just a crawler. Here's what's in it, including where each piece stops:

• Crawl discovery, in three depths. FastCrawl is a quick link/HTTP pass with a 10-page default. DeterministicPass is a Playwright pass without AI that visits same-domain links, fills forms, clicks buttons and captures console errors and DOM snapshots — default cap 25 pages. DeepCrawl adds multi-pass element discovery, form interaction, wizard walking and AI-assisted gate-form analysis — default cap 40 pages. All three share a hard ceiling of 60 pages, and the bound can be widened toward the site's estimated size, so those numbers are defaults, not promises of full coverage. Credits are priced by complexity, so scanning a small site costs less than a large one.
• Auto Scenarios — AI-generated scenarios from the crawled DOM for the categories it can derive: browser flows, API checks, data injection, visual, liveness and console/network drafts. Generation is not execution: Auto Scenarios always runs a deep crawl, builds drafts, and never runs a request against your site. Its two price tiers differ by scope — a whole-domain crawl versus a single-page seed.
• Scenario Recorder — a Chrome extension and an in-app recorder that turn real user flows into replayable scenarios. Runtime selector healing is recorded as a review-only suggestion you approve; the runner does not silently rewrite your scenario.
• Scenario Sets & Scheduling — group browser scenarios into a set, run the set on a timer, and get notified. A scenario promoted from an API test or a Gremlins finding runs through the same browser engine, which is how those families end up on a schedule at all.
• Data Injection — run one form scenario once per row of generated or uploaded CSV data. Values are mapped to the scenario's existing fill steps by selector; application-managed hidden fields (CSRF, session, one-time tokens) are never written; a run is capped at 100 rows.
• Gremlins chaos testing — a browser horde of random clicks, scrolls, typing and form fills, with a baseline check before it starts so pre-existing errors aren't blamed on the monkeys. On the shared pool a run is capped at 200 actions; a run on your own local runner can go higher, because the cap is about protecting shared capacity rather than probing them differently.
• Visual regression, liveness monitoring, load testing, API testing — each with its own engine and its own reporting.
• Console & network capture, HTML/JSON reports — so when something does fail you can see why. Gremlins findings land on the Bugs page instead of being a console log you have to read twice.
• A CI API with scoped tokens — CI tokens can start and read runs and download reports, and nothing else: they cannot change monitors, spend on anything but a run, or touch billing.
• Requirements & traceability, a local runner for browser scenarios and CI work, real-time notifications, and credit-based pricing.

That list is a map, not a promise of uniform coverage. The honest version matters more than the marketing one, so here are the limits that surprised people (and me):

• CI runs browser scenarios. Gremlins, data injection, visual, load and liveness tests are not startable from the CI API yet. An API test can be promoted to a browser scenario, and then it runs in CI like any other scenario.
• Scheduling exists for browser scenarios and liveness checks. The specialised families are run on demand.
• Where Gremlins run depends on where you send them. The default is the shared server pool, capped at 200 actions; choosing your own local runner removes that cap, and if the runner is not eligible the run is refused rather than quietly moved to the server. A horde that runs on a local machine is a local run — it is not evidence that a shared-pool run behaves the same way, so check the run's reported execution location before drawing conclusions.
• Local runs still upload their results to your Qalizer account. There is no "nothing leaves my machine" mode today.

I prefer writing those limits down over discovering them in a support conversation.

Where the idea came from

The features above were built because my own projects needed them, not because a customer asked. My side projects have a UI, forms, a login and a checkout, and every one of those is a place where "I'll test it later" turns into a bug report from a user. Everything I wanted existed as a manual step in my own workflow — crawl the app, write the obvious tests, find a way to replay a bug, get the regression into CI — so I automated the steps I kept doing by hand.

That's the whole origin story: I built the tool I wanted to buy, then kept adding the parts I personally missed.

What I got right

Three decisions held up better than I expected.

Pay-per-action pricing. Prepaid credits fit how I use QA: a burst around a release, quiet in between. A new account gets 100 signup credits when it is created — a signup grant, not a monitor-creation bonus — each action shows its cost before it runs, and there is no subscription between you and a feature. If a crawl turns out to be the only thing you needed, that's fine: you spent credits on it and stopped.

Crawler-first test discovery. Hand-written test lists rot. Crawling the real DOM and classifying pages means coverage starts from what you actually ship. When you add a page, the next crawl can find it — you don't have to remember to add it to a test plan.

Not silently rewriting my own scenarios. Selector healing on a recorded flow is genuinely useful, and the most valuable part turned out to be the one I didn't design first: a heal is suggested for review rather than applied behind my back, so a green run still means the scenario I wrote passed. It is a suggestion, not a guarantee — a big DOM rewrite will still break a scenario and it will need a human.

What I still haven't solved

Honesty requires the flip side. Qalizer is not a cure-all.

I still haven't perfectly solved test flakiness on complex single-page apps. Massive stateful frontends can still produce results that depend on network conditions and timing, and a single run is rarely enough evidence to call a failure a regression. I've mitigated it, not eliminated it.

Login-dependent crawling remains genuinely hard. If your app hides everything behind authentication, the crawler has to model getting past that wall, and session handling in headless browsers is fiddly. The deterministic pass can flag a credential wall and hand you a gate scenario; deeper stateful gates are the slower, less certain path.

And I'll admit that AI-generated tests are a floor, not a ceiling. They give you broad coverage of what a machine can infer from your DOM, but they don't know your business rules, so they won't replace a human designing a subtle negative case around them. Plan to add hand-written scenarios on top.

There is one more caveat that matters if you're evaluating this today: Qalizer is in a paid public beta. Features, limits and the interface can still change, runs can be queued or delayed when the pool is busy, and prices can change during the beta. I'd rather you know that before you pay for credits than after.

Why this matters for indie makers

Here's the honest pitch, stripped of hype. If you're a solo developer or small team, you have two choices today: skip testing entirely and hope, or burn your limited time assembling and maintaining a DIY stack. Qalizer is a third option — a platform that does the discovery and generation work for you, priced in prepaid credits so you can start with the 100 signup credits and scale only as your product actually makes money.

My side projects deserve better than "I'll test it later." So do yours.

The feature list above is real, limits included, and the platform runs on the same idea that started all of this: crawl first, test what's really there, and don't charge a subscription for it. I'd rather you spend your evening shipping features than writing yet another Playwright config.

If any of this resonated — especially if you've abandoned the idea of testing your side projects because the tools were too expensive or too heavy — this was built for that case. You can create an account and the 100 signup credits are added when it's created, no credit card required.