How we dogfood venkat.ag.

Yes, we use it. Every PR.

Every team building a developer tool eventually gets asked the same question: do you actually use it yourselves? For a QA product, that question has extra bite. If our own agent can't keep our own app stable, there's no reason you should trust it with yours.

So yes — we use Venkat to test Venkat. Every pull request against our dashboard, our marketing site, and our mobile companion app is tested by the same agent we sell, running against the same preview deployments you would use.

But honestly, we didn't wire it up to make a point. We wired it up because it's the fastest feedback loop we have. When a run is flaky, we feel it before a customer does. When writing a test is annoying, we get annoyed first. A surprising number of product decisions started as one of us complaining about our own internal test suite.

“We ship Venkat with Venkat. If we can't dogfood it, you shouldn't trust it.”

The suites we maintain

Venkat is a tool for testing your apps, so our main use case is the obvious one: testing Venkat itself. We maintain a handful of named test groups across our surface area — everything from checking that 404 pages render correctly, up through full sign-up and project-creation flows on web and native.

• marketing/critical — the landing page, pricing, and blog. Broken links kill trust; we watch them like hawks.
• dashboard/onboarding — sign up, connect GitHub, invite teammate, first run.
• dashboard/pr-checks — the meta-suite: dashboards for GitHub PR statuses.
• mobile/ios/native — the iOS companion, running on real-device runners + iOS Simulator over on the AWS side.
• mobile/android/native — same story on the Android emulator.

The full group runs on a schedule every three hours. Regressions surface within hours of landing instead of days, which usually means we can fix them before anyone hits them.

Shipping with confidence

In the agentic era, code gets written faster than ever — which means bugs ship faster than ever too. Catching them after deploy isn't good enough anymore.

So besides the schedule, every pull request in our repo gets a Venkat run against its preview deployment. The result lands as a check on GitHub, right next to the type-check and unit tests. If the agent finds a regression, we know before merge, not after — and we ship with confidence.

✓ venkat / marketing/critical    24 flows   passed   1m 42s
✓ venkat / dashboard/onboarding  11 flows   passed   2m 08s
✗ venkat / dynamic (PR #482)      1 finding  see report
    └─ 03 · Stripe payment element blank on iPhone 16 Pro width

Tests that adapt to you

Predefined tests only cover what we thought to write down. That's why our PR runs also include dynamic tests: the agent reads the pull request — the diff, the description, the linked issue — and plans a fresh set of steps targeting exactly what changed. Whatever the saved suites don't cover, the dynamic plan goes after.

This matters because a test suite that only knows yesterday's app goes stale fast. Dynamic tests adapt to the codebase as it changes, so you don't need to write a new test for every feature you ship. Especially useful for a solo-founder team like ours where writing tests is often the thing that gets skipped last on a Friday night.

Let a coding agent set up your tests

Earlier I said we maintain these tests — that was not entirely true. We let agents do that for us.

We rarely click through the dashboard to create tests. Venkat has a first-class CLI (venkat), and our coding agents use it to manage QA for us. When a coding agent finishes a feature in our repo, it can:

• save a regression test for the new flow with venkat tests create;
• queue a remote run with venkat tests run <testId> --wait and read back the result;
• point runs at the right target with saved environments (venkat env use staging);
• store durable knowledge about the app with venkat memories create, so future runs already know its quirks.

The result is that test coverage grows in the same pull request as the feature, without anyone context-switching into a dashboard. If you're a founder-engineer running lean, this is the thing that will save your neck.

$ venkat tests create \
    --name "Waitlist CTA · Venkat landing" \
    --target https://preview.venkat.dev \
    --plan "Open landing, scroll to #start,
            fill email with test+42@venkat.dev,
            submit, expect confirmation toast."
✓ saved as test_2z7f · will run on next PR

Where it doesn't help (yet)

There are still changes the agent can't test for us. GitHub App logic is the best example: verifying it means acting across multiple applications — pushing commits, watching webhooks arrive, checking what shows up on the pull request. Those flows we still verify by hand.

We're actively extending the agent's capabilities to cover more of these cross-system cases, and the mobile-native runners (real-device fleet + iOS Simulator, Android emulator) already do a lot of the heavy lifting there. If you're staring at a hairy cross-app QA problem, email us — that's how our roadmap gets sharper.

Takeaways — steal our setup

If you're thinking about adopting Venkat, steal the shape of what we do:

• Let a coding agent bootstrap your tests through the CLI instead of configuring everything by hand.
• Enable dynamic tests so coverage adapts to every pull request automatically.
• Schedule your core groups — every 1–3 hours in prod — so regressions surface in hours, not days.
• Wire the check into GitHub so a red Venkat run blocks merge, same as your unit tests.
• Save memories the first time a real bug is caught. Future runs won't have to rediscover it.

That's it. That's how we test Venkat with Venkat. First run is free — point us at your app and see what breaks.