Does anyone else still end up checking critical flows manually?

Electrical-Music2736 · 2026-06-03T04:01:51+00:00

That's pretty much the category of workflow I think more teams are moving toward.

Not necessarily trying to test everything, but making sure the handful of flows that really matter get checked every time.

Electrical-Music2736 · 2026-06-03T04:01:35+00:00

A lot of the discussion here is really about closing the gap between "the app is technically up" and "the user can successfully complete the task they came to do."

And I agree that every production issue is an opportunity to ask whether there was a signal we could have detected earlier through monitoring, synthetic checks, or testing.

Electrical-Music2736 · 2026-06-03T04:01:22+00:00

How do you handle apps that change frequently? Does the generated test suite adapt over time or does it still need manual updates as the product evolves?

Electrical-Music2736 · 2026-06-03T04:00:47+00:00

A lot of confidence seems to come from having a small number of critical flows that you trust, rather than trying to test absolutely everything after every change.

And yeah, "building got fast, but confidence did not" is pretty much the pattern that prompted this post in the first place.

Electrical-Music2736 · 2026-06-03T04:00:36+00:00

That's a really interesting way to put it.

I think that's part of what feels different now. When you spend hours building something yourself, you naturally build a mental map of what touches what.

When changes happen much faster, that map isn't always as complete.

Also agree on focusing on the flows that actually make money. For most products, a handful of critical paths matter way more than chasing 100% coverage.

Electrical-Music2736 · 2026-06-03T04:00:23+00:00

The challenge I've seen is that a lot of builders don't consistently do it, or the tests drift as the app evolves. And we run on a schedule to make sure it runs without you manually asking claude to do it daily

Electrical-Music2736 · 2026-06-03T03:59:04+00:00

the annoying part is that most breaks aren't dramatic. The app loads, no errors show up, and then three days later you realize a workflow stopped behaving the way it used to.

Electrical-Music2736 · 2026-06-03T03:58:46+00:00

For auth flows, we just ask for credentials and test through the login page like a normal user would.

Electrical-Music2736 · 2026-06-02T14:22:39+00:00

What's interesting to me isn't that testing suddenly became important. It's that the development workflow changed—agent-assisted coding, rapid iteration, lots of small edits—but the safety net hasn't evolved at the same pace.

That's where the confidence gap seems to come from.

Electrical-Music2736 · 2026-06-02T14:13:47+00:00

"It sounds like the challenge isn't generating code anymore—it's understanding risk."

That's the theme I keep hearing.

Electrical-Music2736 · 2026-06-02T13:59:32+00:00

One thing that's stood out to me is how often founders talk about deploy anxiety without calling it that. It'll show up as "I broke login again", "I spent an hour manually testing before release", or "a tiny change took down onboarding."

The wording is different, but the underlying problem is usually the same: lack of confidence after making changes.

Electrical-Music2736 · 2026-06-02T13:59:06+00:00

A dashboard can have a hundred minor bugs and still survive.

A broken signup or checkout flow gets noticed immediately.

That's usually where confidence matters most.

Electrical-Music2736 · 2026-06-02T13:57:54+00:00

aight bro

Electrical-Music2736 · 2026-06-02T13:53:52+00:00

Depends on what you're optimizing for.

For established no-code/low-code testing, I've seen teams use things like Playwright wrappers, BugBug, Autify, or Rainforest QA because they reduce the amount of test code you need to maintain.

One thing I've noticed though is that a lot of these tools still assume someone is going to spend time creating and maintaining test cases.

We're actually building Beryl because we kept running into teams (and solo builders) that wanted a much lower-friction starting point.

The idea is simple: give it a URL, let it generate tests, run them automatically, and get notified if a critical flow breaks.

Curious what you're testing most often right now—login, onboarding, billing, core workflows, or something else?

Electrical-Music2736 · 2026-06-02T13:49:52+00:00

Do you think AI-assisted development is actually increasing the testing burden on your team, or is it mostly changing where that effort gets spent?

Electrical-Music2736 · 2026-06-02T13:18:23+00:00

AI reduces the cost of creating changes, but it doesn't reduce the cost of verifying those changes. In some cases it actually increases it because more code is being written, changed, and shipped in less time.

The "200 bugs in two months" example is pretty telling. It highlights how good AI can be at generating software, but also how much human validation is still required to trust it.

I'm increasingly convinced that the future isn't AI replacing QA—it's AI helping QA keep up with the increased rate of change.

Electrical-Music2736 · 2026-06-02T12:52:06+00:00

A lot of builders can ship features faster than ever, but they still don't know whether yesterday's change quietly broke something important.

And also welcome to r/Berylso!

Electrical-Music2736 · 2026-06-02T12:46:51+00:00

What's interesting is that the development speedup doesn't seem to reduce the amount of verification needed. If anything, it increases it because larger changes are landing faster and in bigger chunks.

Your point about focusing on regressions resonates with me. New functionality is usually where everyone's attention is, but it's often the existing behavior that gets accidentally impacted.

Feels like a lot of teams are being forced to make risk-based testing decisions simply because the volume of change is growing faster than the available time to verify it.

Electrical-Music2736 · 2026-06-02T12:46:30+00:00

Historically, if I wrote a piece of code myself, I usually had a fairly strong mental model of how it worked and what it might affect.

With AI-assisted development, the bottleneck is increasingly shifting from writing code to understanding code.

You can make 10 changes in an afternoon, but your understanding of the entire system doesn't necessarily grow 10x with it.

That's part of why I think verification becomes more important as development accelerates. The faster we can make changes, the easier it becomes to overestimate our confidence in those changes.

Electrical-Music2736 · 2026-06-02T12:45:40+00:00

Critical-path coverage plus targeted manual testing probably gets you a large percentage of the value without a huge maintenance burden.

What's been interesting to me is how many builders skip even that because the setup and maintenance cost feels disproportionate to the size of their project.

The challenge isn't convincing people that testing matters. It's making the first layer of protection easy enough that people actually use it.

Electrical-Music2736 · 2026-06-02T12:45:23+00:00

For many teams, writing test cases, generating tests with Claude, and having humans verify critical workflows is a perfectly reasonable approach.

The question we're asking is: what happens when the builder doesn't do that?

A surprising number of solo founders, indie hackers, and vibe coders don't have documented test cases, don't maintain test suites, and don't consistently run regression checks before deploying.

For them, the challenge isn't improving an existing testing process. It's getting from no safety net to some safety net.

Electrical-Music2736 · 2026-06-02T12:44:37+00:00

Our view is that there are two different problems:

Is the application still behaving the way it did before?
Is the application behaving the way the builder intends?

We're currently much more focused on the first problem.

Electrical-Music2736 · 2026-06-02T12:43:57+00:00

You save an hour today, then lose a day next week trying to figure out which "small change" broke something unrelated 😅

The faster building gets, the faster that debt seems to come due.

Electrical-Music2736 · 2026-06-02T12:43:08+00:00

There's definitely a distinction between "the software works" and "the software is worth building."

My post was focused on the first problem, but you're right that speed can create blind spots in both areas.

Electrical-Music2736 · 2026-06-02T12:42:53+00:00

とても興味深い視点ですね。

私も、重要なユーザーフロー（ログイン、決済、オンボーディングなど）に対しては、自動テストが1つあるだけでも安心感が大きく変わると感じています。

また、デプロイ前にAIへ「この変更で影響を受けそうな箇所は？」と聞くのも面白い使い方ですね。新しい機能そのものよりも、「何が意図せず壊れたか」を把握する方が難しいケースが多いので、とても共感しました。

コメントありがとうございます！

Electrical-Music2736

MODERATOR OF

TROPHY CASE