DEV Community: Luca Müller

Browser Automation Myths Teams Still Believe, and What to Compare Instead

Luca Müller — Wed, 03 Jun 2026 20:26:40 +0000

A believable misconception is that if a tool can click buttons in Chromium, it is probably good enough for browser automation and cross-browser testing. That idea sounds efficient, especially when the team is under pressure to ship. But when the goal is confidence across browsers, viewports, CI, and real user flows, the tradeoffs show up quickly.

The hard part is not finding a tool that can run tests. The hard part is choosing one that gives you the right coverage, keeps tests readable over time, and fails in ways your team can trust.

Myth 1: If the tool runs the test, the browser coverage is solved

The reality is that browser automation coverage is only useful if it matches the browsers and devices your users actually depend on. A tool might support multiple browsers on paper, but still leave gaps in mobile web behavior, responsive layout checks, or Safari-specific issues.

When teams compare tools, they often ask, “Does it support Chrome, Firefox, and Safari?” That is a good start, but not enough. You also want to ask:

Are those browsers real, current engines, or close enough emulations?
Can the tool test responsive breakpoints without turning every test into viewport math?
Can it exercise mobile web behavior in a way that reflects the browser stack your customers use?

A useful way to think about this is to separate browser support from browser confidence. Support is the checkbox. Confidence is whether the tool helps you detect the bugs that matter.

For a practical buying lens on viewport checks, mobile browser testing, and breakpoint validation, the guide How to Evaluate Test Automation Tools for Mobile Web and Responsive Layout Coverage is a good companion. Even if you are not buying a new tool, the criteria are useful for pressure-testing your current setup.

Myth 2: One automation tool should cover everything equally well

Reality is messier. The best browser automation tools are usually good at some things and merely adequate at others. That is not a flaw, it is a constraint you should plan around.

For example, a team may choose one tool for functional browser tests, another approach for visual regression, and a separate strategy for tricky edge cases like file uploads or drag-and-drop flows. That does not mean your stack is fragmented. It means you are matching the testing method to the risk.

The goal is not to ask every tool to do every job. The goal is to avoid forcing brittle patterns into places where they do not belong.

Consider file upload flows. They often look simple in the app, but the underlying test can become flaky if you rely on brittle selectors, hidden inputs, or fake user paths that do not mirror the browser interaction closely enough. The article How to Test File Upload Components in Modern React Apps Without Flaky Selectors is a useful example of why reliable locators and CI-friendly patterns matter more than tool branding. The lesson generalizes: stable tests come from stable interaction patterns, not just from picking a popular framework.

Myth 3: Real Safari testing is just another browser checkbox

Safari is where the difference between “supported” and “reliable” often becomes obvious.

Teams sometimes assume that if a test passes locally in a WebKit-like environment, Safari on CI will behave the same way. In practice, it may not. Timing, storage behavior, rendering quirks, and environment-specific constraints can expose issues that do not appear elsewhere.

That is why real browser coverage matters. When you compare tools, look beyond whether they can launch a Safari session. Ask what kind of evidence you get when something fails, what logs you can capture, and how much work it takes to stabilize the test after a failure.

A deeper operational view appears in Real Safari Testing on CI: What Breaks, What to Log, and How to Stabilize It. The practical value there is not just “Safari is flaky.” It is understanding what makes Safari failures diagnosable, which is a big part of reliability.

If your team cannot explain a failure from logs and artifacts, then a passing automation suite is not giving you much real confidence.

Myth 4: A green CI run means the suite is reliable

Reality: a green run only means the suite passed this time. Reliability is about whether the suite fails for the right reasons, in a way the team can reproduce and act on.

This is where compare-and-pick decisions get serious. A tool that is fast but opaque can be less useful than a slightly slower tool that gives you video, network logs, trace data, and a clean retry story. That is especially true when browser behavior depends on timing, external APIs, fonts, or session state.

When evaluating tools, ask what evidence you get on failure:

Can you see video of the actual session?
Can you inspect network requests and responses?
Can you rerun only the failing scenario without rebuilding the world?
Can you tell whether the failure is in the app, the test, or the environment?

These questions matter because cross-browser failures rarely announce themselves clearly. Sometimes the UI never loaded. Sometimes the selector was fine, but the browser rendered differently. Sometimes the test was correct, but the environment was not.

A practical breakdown of what to collect in CI is covered in How to Test Browser Sessions in CI When You Need Real Devices, Video, and Network Logs. Even if your setup is lighter weight, the same principle applies: evidence is part of test reliability, not an optional extra.

Myth 5: Maintainability is just a code style preference

Reality: maintainability is a test strategy concern.

A suite that is hard to read, hard to update, or tightly coupled to implementation details becomes expensive the moment the UI changes. In browser automation, this usually shows up as fragile selectors, repeated setup logic, and tests that encode too much of the page structure.

When comparing tools, do not stop at “Can it automate this flow?” Ask whether it helps teams write tests that survive normal product change. A maintainable tool usually makes it easier to do a few important things well:

Prefer accessible, stable locators over deeply nested CSS paths
Keep page interactions at the user level, not DOM implementation level
Make test data setup explicit and reusable
Keep failure output easy to interpret

This is where a lot of cross-browser pain is actually created. A test suite can be technically correct and still be impossible to maintain if it treats every browser-specific quirk as a special case scattered across dozens of files.

Visual checks are a good example. Teams shipping frequent UI changes often need a layer that catches layout regressions without turning every small styling tweak into a maintenance event. The article Best Visual Regression Tools for Teams Shipping Frequent UI Changes is helpful because it frames visual testing as a workflow decision, not just a tool selection exercise.

Myth 6: Cross-browser regression means rerunning the same suite everywhere

Reality: not every test deserves equal browser coverage.

A smarter cross-browser strategy is selective. Core user journeys may need broader browser coverage. Narrow utility behavior may only need one or two browsers. Layout-sensitive pages may need breakpoint checks. High-risk flows may need real-device validation. The challenge is to define those layers clearly, then automate them in the right place.

This is where teams often get stuck, because they try to turn browser automation into a single monolithic quality gate. That usually leads to slow pipelines and noisy failures. Instead, compare tools by how well they help you separate concerns:

Functional coverage for critical flows
Responsive coverage for layout-sensitive screens
Visual regression for unintended UI changes
Real-browser verification for browser-specific behavior

If you want a clear practical discussion of where to automate and where browser differences usually surface first, Endtest for Cross-Browser Regression: What to Test, What to Automate, and What Still Breaks is a strong reference point. The useful takeaway is not the specific tool, it is the decision-making model.

What teams should compare before choosing a tool

If you boil all of this down, the comparison is less about feature count and more about fit. The better questions are:

Does the tool cover the browsers and real engines our users depend on?
Does it help us test responsive behavior without turning tests into brittle viewport scripts?
Can we debug failures quickly with logs, video, and other artifacts?
Will the test code stay readable as the product changes?
Does it encourage stable locators and user-level interactions?
Can we scale coverage without making CI slow and noisy?

That list is more useful than a marketing matrix because it maps directly to team pain. If a tool fails one of those questions, the cost usually shows up later as flaky tests, slower merges, or blind spots in production coverage.

The more useful mindset

Browser automation is not a contest to see which tool can simulate the most clicks. It is a way to create trustworthy signals about how your product behaves in real browsers, on real layouts, under real CI constraints.

So when a team says, “We need cross-browser testing,” the next question should not be, “Which tool has the longest feature list?” It should be, “Which tool helps us cover the browsers that matter, write tests we can maintain, and debug failures we can trust?”

That framing leads to better decisions, and usually fewer surprises after the first big UI release.

Build an AI-Powered Money Printing Machine

Luca Müller — Fri, 08 May 2026 21:48:41 +0000

Okay, first of all:

This is not financial advice.

This is not startup advice.

This is not legal advice.

This is barely even advice.

This is more like that moment at 1:13 AM when you realize that some random AI app is making more money than a regional airline, and you start whispering to yourself:

“Wait. I could build a worse version of this.”

And honestly?

That is not always a bad place to start.

A lot of people think startup ideas need to appear like lightning from the heavens.

They imagine the founder standing in the shower, shampoo in one eye, suddenly discovering a completely new market category.

But a much more boring and reliable approach is this:

Find a product that is already working.
Ask why people are paying for it.
Build a more focused, cheaper, simpler, weirder, or more niche version.
Sell it to people who already understand the problem.

That is the “money printing machine.”

Not literally.

If it were literal, I would be writing this from a yacht called npm install passive-income.

But metaphorically, the pattern is real.

Validated market + AI leverage + distribution = something worth building.

Let’s look at a few examples.

The boring secret: competition is not always bad

New founders often say:

“But someone already built this.”

Yes.

That is the point.

If nobody built it, maybe you are a genius.

Or maybe you are about to spend 8 months building an AI-powered dashboard for left-handed alpaca accountants and discover the market size is 3 people and one of them is your cousin.

Competition means the market has already been educated.

People are searching for it.

People are paying for it.

People are complaining about the existing options.

People want alternatives.

That last part is where you come in.

You do not always need to invent a category.

Sometimes you can enter an existing category with one of these angles:

cheaper
faster
simpler
more niche
more private
better UX
better onboarding
built for a specific profession
built for a specific country
built around a specific workflow
built with fewer enterprise sales calls, which honestly should qualify as a humanitarian effort

AI makes this especially interesting because it reduces the cost of building the first version.

Not the cost to zero.

Never believe anyone who says software is free now.

But it does reduce the cost of creating something useful enough to test.

Example 1: BibleChat and the “public domain brain” business

Religious AI apps are a fascinating category.

Take something like BibleChat.

The basic idea is simple:

Ask questions, get Bible-based answers, read verses, journal, reflect, pray, study, build a habit.

That is a real product category now.

And this is not just a cute little side-project category either. Public reports say BibleChat reached around $15 million in annualized revenue / 2024 revenue after scaling extremely fast.

That should make every indie hacker stop scrolling for a second.

Because the interesting part is that the core content is not some proprietary McKinsey database that costs $500,000 to license.

A lot of religious, philosophical, historical, and classical texts are either public domain, freely available, or accessible through licenses that are much cheaper than building a content library from scratch.

The Bible is the obvious example.

But you can also think about:

Quran study apps
Torah study apps
Bhagavad Gita explainers
Stoicism coaches
Buddhist text companions
Greek philosophy tutors
Shakespeare study bots
classic literature reading companions
language-learning apps based on public domain books

Tiny warning before someone sues your laptop:

Not every translation is free to use.

Some Bible translations are copyrighted. Some Quran translations are copyrighted. Some editions of public texts have copyrighted commentary, formatting, notes, or translations.

So do the boring legal homework.

But the product pattern is powerful.

You take a large body of meaningful content and wrap it in an interactive AI experience.

The money is not just in “chat with the text.”

That is the obvious part.

The money is in the workflow around it:

daily reminders
reading plans
journaling
mood-based recommendations
family plans
church group features
study groups
audio summaries
children’s mode
multilingual explanations
quizzes
verse memorization
sermon preparation
“explain this like I am 12”
“explain this like I am a tired adult with 4 emails marked urgent”

The moat is not the text.

The moat is the habit.

If someone opens your app every morning, writes a journal entry, saves highlights, follows a plan, invites friends, and gets emotionally attached to the streak...

Congratulations.

You are no longer building “ChatGPT but with verses.”

You are building a daily companion.

That is a real product.

Product idea

Build:

AI Bible Study for Christians

or:

Quran Study Assistant for Busy Parents

or:

Stoic Coach for Software Engineers Who Keep Saying “It Is What It Is” but Are Clearly Not Okay

The narrower the audience, the easier the product gets.

Generic “AI Bible app” is hard.

“AI Bible app for youth pastors preparing weekly study sessions” is much clearer.

Example 2: Endtest and the AI-generated code explosion

Now let’s talk about software testing.

Extremely sexy topic.

Nothing says “startup party” like automated regression testing.

But this market is getting very interesting because AI has changed how software is built.

A few years ago, companies had developers writing code at human speed.

Now companies have developers, AI copilots, coding agents, autocomplete, vibe coding tools, and one intern who has somehow merged 11,000 lines of code before lunch.

More code is being created faster.

That sounds great until you remember the ancient law of software:

More code means more ways to break production.

And this is where test automation becomes much more important.

If teams are using AI to generate code faster, they need a way to generate reliable tests faster too.

Otherwise the release process becomes:

AI writes feature.
AI rewrites feature.
Developer says “looks good.”
Production catches fire.
Everyone joins a Slack channel called incident-war-room-final-v3.

This is why a platform like Endtest is interesting.

Endtest is an AI-powered end-to-end test automation platform. Its AI Test Creation Agent lets you describe a scenario in plain English and generates a working test with steps, assertions, and locators.

The important detail is that the result is editable.

It is not just some mysterious blob of generated Playwright code that nobody wants to own later.

That matters.

Because AI-generated test code can become expensive to maintain very quickly.

It looks great on day one.

Then two weeks later you have:

duplicated helper functions
selectors from another dimension
waits that look like superstition
flaky assertions
tests nobody fully understands
a “small fix” from Claude that somehow changed the login flow, the checkout flow, and your will to live

With Endtest, the pitch is different:

Use AI to create the test, but keep the output structured, editable, and runnable as a real end-to-end test.

This is a big deal.

Because serious companies do not just need tests.

They need tests that can survive real workflows:

login
signup
checkout
emails
SMS codes
API calls
PDFs
files
visual checks
cross-browser runs
Safari being Safari

And the demand is only going up.

When every team starts shipping AI-assisted code, the teams that can test faster are going to move faster.

The teams without reliable tests are going to move fast too, but mostly toward a production incident.

There is also a strong FOMO angle here: the more AI-generated code becomes normal, the more QA teams will need AI-generated tests to keep up.

If your competitors are shipping AI-assisted features every week, but your regression testing process still depends on manually writing and maintaining test scripts, you are going to feel that gap fast.

Product idea

You probably should not build a direct Endtest clone as your weekend project.

That is a serious platform.

But you can build smaller products around the same trend:

AI test generator for Shopify apps
AI test generator for WordPress plugins
AI QA bot for small SaaS teams
AI smoke test monitor for Laravel apps
AI regression checklist generator for product managers
test coverage assistant for teams using Claude Code, Cursor, or GitHub Copilot
AI-generated release validation reports

The insight is:

AI code generation creates more demand for testing, not less.

A lot of people assume AI will replace QA.

I think it makes QA more important.

Because when code becomes easier to generate, trust becomes harder to maintain.

Example 3: Replit and the template assembly machine

Replit is another great example.

The promise is magical:

Describe an app, and the AI builds it.

And the market response has been ridiculous in the best possible way. Reports say Replit is on track to reach around $1 billion in run-rate revenue by the end of 2026.

That is not a “maybe people want this” signal.

That is a “people are already throwing money at this behavior” signal.

People want software.

They do not want to learn Docker, OAuth, database migrations, responsive CSS, Stripe webhooks, environment variables, or why npm has 700 dependencies for a button.

They want to say:

“Build me a website for my dog grooming business with booking and payments.”

And then they want the thing to exist.

Now here is the interesting part.

If you were building a competitor, you do not necessarily need to generate every single line from scratch.

In fact, you probably should not.

A more reliable architecture might look like this:

Create a library of templates.
Create reusable components.
Create reusable backend modules.
Let AI pick, combine, configure, and style them.
Only generate custom code when needed.

For example, you could have reusable components like:

Login
Signup
Password reset
Pricing table
Contact form
Booking calendar
Admin dashboard
Blog
File upload
Checkout
User profile
Notifications
Email templates

And backend modules like:

authentication
user roles
payments
subscriptions
CRUD tables
comments
uploads
analytics
email sending
database schemas

Then when a user says:

“Build a website for a dental clinic”

Your AI does not need to invent authentication from scratch like a caffeinated raccoon.

It can assemble:

dental homepage template
appointment booking component
contact form
admin dashboard
login module
database schema for appointments
notification email template

Then it styles the whole thing.

This is less “AI writes everything.”

It is more:

AI is the project manager, designer, and glue layer.

That can be much more reliable.

Because reusable components are tested.

Templates are stable.

Backend modules are known quantities.

The AI is not hallucinating a login system for every customer. It is reusing the same login system and customizing the surface.

That is probably the difference between:

“Wow, this demo is incredible.”

and:

“Wow, this product still works after 200 customers.”

Product idea

Do not build “Replit, but worse.”

Build:

AI website builder for dentists
AI booking-site builder for local service businesses
AI app builder for internal tools at small companies
AI portal builder for schools
AI dashboard builder for agencies
AI marketplace builder for niche communities
AI SaaS builder for boring B2B workflows

The riches are often in boring niches.

Nobody wants to say they are building “AI CRM for asphalt contractors.”

But asphalt contractors have money.

And they probably do not want to configure Supabase.

Example 4: Cursor and the specialized AI coding assistant

Cursor is a monster example of this category.

It proved that developers will pay for AI tools when the tool fits directly into their workflow.

But you do not need to beat Cursor head-on.

Please do not wake up tomorrow and say:

“I will build a better AI code editor than Cursor.”

That is how you end up crying into a VS Code extension manifest.

Instead, look for specialization.

Cursor is broad.

You can be narrow.

For example:

AI coding assistant for legacy PHP apps
AI refactoring assistant for Laravel
AI migration assistant from AngularJS to React
AI code reviewer for security-sensitive fintech teams
AI assistant for WordPress plugin developers
AI assistant for Shopify theme developers
AI database migration copilot
AI test writer for Python 2.7 codebases, for the 14 companies still trapped there like it is a cursed museum exhibit

The pattern is simple:

Big AI products validate the behavior. Small AI products can own the workflow.

If Cursor proves people want AI inside the coding process, you can build a focused assistant for a specific pain.

The narrower tool can win by knowing the domain better.

Generic AI says:

“Here is a possible solution.”

Specialized AI says:

“I know this exact stack, this exact framework, this exact error, and the three terrible reasons your team cannot upgrade it yet.”

That is valuable.

The “validated competitor” framework

Here is the simple process.

Step 1: Find a product that is already working

Look for signals:

people pay for it
people complain about pricing
people search for alternatives
people write comparisons
people ask about it on Reddit
companies buy it
influencers demo it
competitors are appearing

The phrase “alternative to X” is basically a treasure map.

If people search for:

“cheaper alternative to X”

that is not a keyword.

That is a business plan wearing a fake mustache.

Step 2: Pick the wedge

Do not clone the whole product.

Pick one wedge.

Examples:

cheaper
simpler
faster
privacy-first
team-specific
region-specific
industry-specific
integrates with one tool really well
does one workflow better than everyone else

Your first version should feel almost embarrassingly narrow.

That is good.

Narrow is how small teams survive.

Step 3: Use AI where it creates leverage

AI is not the product by itself.

AI is a lever.

Good places to use it:

natural language input
summarization
classification
recommendations
content generation
code generation
test generation
support automation
onboarding
template selection
personalization

Bad places to use it:

anything where being confidently wrong destroys trust
anything where the user needs deterministic behavior
anything where the AI is secretly replacing a database query because the founder was “moving fast”

Use AI where fuzziness is acceptable.

Use boring code where correctness matters.

Boring code is underrated.

Boring code pays rent.

Step 4: Build reusable primitives

This is the Replit lesson.

If you are generating everything from scratch, your product may become unreliable.

Reusable primitives make AI products stable.

Examples:

templates
components
workflows
prompts
schemas
validation rules
test cases
integrations
style presets
reusable backend modules

The AI should not be a drunk intern with root access.

It should be an orchestrator.

Give it safe building blocks.

Step 5: Price against frustration

People pay when the current solution is painful.

Common pricing pain points:

too expensive
too complicated
too enterprise
requires sales call
charges per seat
charges per usage
charges for features people assume are basic
too many limits
surprise bills
bad onboarding
awful docs
support replies in 17 business days

Your product does not need to be cheaper in every way.

It needs to feel like a better deal for your specific customer.

Example:

“Unlimited AI usage for small QA teams”

is more compelling than:

“AI-powered quality transformation platform for enterprise excellence”

One sounds useful.

The other sounds like it was assembled during a SaaS hostage negotiation.

The four examples, summarized

BibleChat-style products

The core insight:

Meaningful text + AI interaction + daily habit = product opportunity.

Build around public domain or properly licensed content.

Make it niche.

Make it habit-forming.

Do not just build “chat with book.”

Build the workflow around the book.

Endtest-style products

The core insight:

AI-generated code increases the need for reliable test automation.

More code means more risk.

More releases mean more regression pressure.

The teams that can create tests faster will ship more safely.

Build products around testing, validation, release confidence, and AI-assisted QA.

Replit-style products

The core insight:

People want software without becoming software engineers.

But full AI generation can be unstable.

Use templates, components, and reusable backend modules.

Let AI assemble and customize.

Do not make it invent authentication from scratch every time.

That way lies madness.

Cursor-style products

The core insight:

Developers will pay for AI if it fits directly into their workflow.

Do not compete with the broad tool.

Go narrow.

Pick a stack, industry, migration path, or painful workflow.

Become the AI assistant for that specific job.

The uncomfortable truth

Most AI products will fail.

This is good news.

Because most of them will fail for boring reasons:

no distribution
no niche
no retention
no willingness to pay
no clear workflow
too much AI magic
not enough actual product
founder spent 3 weeks choosing a gradient

The winners will not just be “AI wrappers.”

They will be workflow products that use AI to make something meaningfully faster, cheaper, easier, or more accessible.

That is the whole game.

Do not ask:

“What can I build with AI?”

Ask:

“What painful workflow already has buyers, and how can AI make it 10x easier?”

That is where the money is.

Final thought

If you want to build an AI-powered money printing machine, do not start with the AI.

Start with the money.

Find where people already pay.

Find where they complain.

Find where they search for alternatives.

Find where the existing tools are too expensive, too complex, too slow, or too annoying.

Then use AI to make a focused version that solves the painful part better.

That is the boring playbook.

And boring playbooks are often the ones that work.

Now go build something useful.

Preferably something with fewer dashboards.

We have enough dashboards.