The Coupa portal is an amazing example because I've had to personally spend ~10+ hours clicking that new invoice button and retyping the exact same info.
If you want to set up monthly billing in Coupa, you just manually create 12 invoices and schedule them out. Each time you have to retype all the account information from scratch, and there are a few landmine buttons on the page that will clear all the forms and make you start from scratch. I can't imagine the thousands of human hours lost every year to just filling out fields in Coupa.
Yes, it's a huge pain from what we've seen. That portal is actually running in production for some of our AR/AP AI customers, and getting browser agents to properly parse that page was difficult -- Coupa injects all the DOM elements through a JavaScript <script/> tag like 2-5 seconds after the page loads, non-deterministically. :)
How do you deal with abuse? We recently had to block all of Browserbase, because someone used their platform for AI training. Generally we're fine with scrapers, but we're not equipped to handle the amount of traffic that some of the browser automation sites can generate.
It really sucks to block an entire service, just because a few of its users can't control themselves. At the same time a lot of SaaS providers makes it impossible to report a single user/tenant and getting a paying user banned just isn't happening.
Generally our use cases are completely different -- if a user is doing scraping, it's been structured scraping on a small (<50) set of sites where they need to be able to pull data from a website as if it was an API call, not as a way to web-crawl and get masses of training data.
We gate full access to the platform partially for this reason. We debated giving fewer than 50 free browser sessions, for example, and have already banned a few accounts from our self-serve today that were unidentifiable/"company accounts" without a legitimate web presence.
That is nice, so many companies don't stop to think how their product might be abused. Love to see that you've given it some thought.
One think I might add: limit how many requests per second your clients can make. Even if they can just scrape a small set of sites, they can still hammer a site into the ground. One of the things I think Google has been doing really well since their start is knowing when to back of a site. So either rate-limit your clients, or back of a site if you see responses slowing down.
We just had a company hit one of our sites pretty heavily, and when asking them of back off a bit, they just asked if we could perhaps rate-limit them. Apparently they don't know how to reduce their traffic themselves.
Hey there! Founder of Browserbase here. If you're seeing any abuse from one of our customers we'd love to hear more. Mind sending more info to paul@browserbase.com?
Commenting because I can't get everyone's email; if you're reading this thread and would be interested in an automation engineering conference please email me at mailto:mail@cadocary.com
What about hybrid automations or human-in-the-loop flows? We have automations where the human starts by logging in, then hands over to the agent. Some parts may even be Puppeteer automated. This also means the session may be long running, typically for months at a time and the agent needs to notify the human again if they get logged out. None of the existing browser automation platforms I have tried make this easy or cost effective, so we are currently trying to build our own. Would love to consider Simplex if this is solved.
Could I ask why the flow starts with a human logging in? Is it because you're using their credentials and/or have some sensitivity around storing their credentials? Or is it something to do with 2FA (we handle 2FA)? Or are you just storing the session data after they log in so you can re-use it for those few months you mentioned?
Re: Puppeteer automation as part of the script -- we have a feature we wrote for one of our customers that we didn't promote to production where you can define a deterministic action in the dashboard that allows you to paste in JavaScript, but we're likely not to push that to prod anytime soon. Could you explain your reasoning for wanting to use Puppeteer still? We've generally seen customers fully switch over to Simplex instead of relying on their original Puppeteer/Playwright scripts -- since we have action caching, the underlying script (click on div locator with this div id, etc.) is pretty similar to what you'd get using Playwright.
Security conscious domain. We do automations on behalf of our clients and they don't want credentials stored. "Handling" 2FA automatically is completely unacceptable, it breaks the entire point of the 2FA security model. Besides, login sometimes involves out-of-band 2FA methods including phone number.
I can totally see the value of agent driven flows for automating flows that are highly dynamic, poorly specified, error prone, zero shot environments, etc, but that doesn't seem to be at all what you are demonstrating here. Maybe your demos could show something more "challenging" to automate?
As someone who has spent a LOT of my time in my career working on browser automation and testing, speed and cost was always key. Even with existing programmatic tools like selenium, playwright, cypress, etc speed and headfull hosting costs were already big issues. This seems orders of magnitude slower and more expensive. Curious how you pitch this to potential customers.
We've generally seen the "easy" flows not actually be easy. Workflows that have complex branching logic (shown when filling out the Aetna form in the first example in the video), structured scraping (the second example we showed in the video), and login/2FA/intelligent multi-agent scraping (shown in the last example in the video), are all things that are difficult to impossible to do with traditional automation libraries.
got it, I only looked at the website not the youtube video you posted above, my apologies. On the website, neither the billing platform demo nor the screenshots in the section below convey this value prop very well. Both sections show what appear to be trivial flows without explanation of some of the underlying complexities.
I suppose if you are hitting your target demographic dead-on with your marketing efforts, the value prop should be completely obvious to them, but still could be more explicit in your differentiation.
replying to myself here... I would be interested to see a more hybrid approach where an AI could step in to help retry / get past failures, or as a way of re-recording automation steps for a flow when something changes, but having AI in the loop for every action all the time feels wasteful at best.
Great! I see that further down in the website, which I did not see before posting this comment. I think this could be valuable to demonstrate / communicate in the billing platform demo which is the first thing you see, and is what captured all of my attention (i never even scrolled down).
Edit: I just re-ran the demo and it seemed way faster this time??? the first time it said GOAL: PRESS_ENTER... (agent proceeds to think about it for 5-8 seconds) which seemed hilarious to me.
Looks nice but that's a pretty steep increase from free trial to the lowest tier of 2500/month. Is there really nothing in between? Like a pay as you use plan?
Currently no, it's just the three options (free vs. $2500/month vs. larger enterprise plans). We do usually offer 2-3 month ramp up periods for the $2500/month plans that are usage based.
To be transparent, we're an early startup, and a big part of that is user validation. We've been lucky to have companies as small as 5 people sign onto our $2500/month plan -- it shows some commitment on their side and helps us understand whether it's a real problem for our users. That's the same reason the $2500/month plan isn't self serve (you have to talk to us first).
We're definitely thinking of adding a pay as you go plan! But we aren't there yet re: our understanding of the market, if that makes sense.
From my understanding, Browserbase mostly provides remote browsers for their users. We also provide remote browsers, but with a lot more infrastructure on top (single/multi web agents, caching/reliability support, an agentic IDE/editor, etc).
not really sure how that differentiates since those things you mentioned are ancillary to main value. Also - browser base is insanely cheaper, but looking at the prices this doesn't look like a real company mainly just a way to have users in free tier (with toy level limits)
The Coupa portal is an amazing example because I've had to personally spend ~10+ hours clicking that new invoice button and retyping the exact same info.
If you want to set up monthly billing in Coupa, you just manually create 12 invoices and schedule them out. Each time you have to retype all the account information from scratch, and there are a few landmine buttons on the page that will clear all the forms and make you start from scratch. I can't imagine the thousands of human hours lost every year to just filling out fields in Coupa.
Yes, it's a huge pain from what we've seen. That portal is actually running in production for some of our AR/AP AI customers, and getting browser agents to properly parse that page was difficult -- Coupa injects all the DOM elements through a JavaScript <script/> tag like 2-5 seconds after the page loads, non-deterministically. :)
How do you deal with abuse? We recently had to block all of Browserbase, because someone used their platform for AI training. Generally we're fine with scrapers, but we're not equipped to handle the amount of traffic that some of the browser automation sites can generate.
It really sucks to block an entire service, just because a few of its users can't control themselves. At the same time a lot of SaaS providers makes it impossible to report a single user/tenant and getting a paying user banned just isn't happening.
Generally our use cases are completely different -- if a user is doing scraping, it's been structured scraping on a small (<50) set of sites where they need to be able to pull data from a website as if it was an API call, not as a way to web-crawl and get masses of training data.
We gate full access to the platform partially for this reason. We debated giving fewer than 50 free browser sessions, for example, and have already banned a few accounts from our self-serve today that were unidentifiable/"company accounts" without a legitimate web presence.
That is nice, so many companies don't stop to think how their product might be abused. Love to see that you've given it some thought.
One think I might add: limit how many requests per second your clients can make. Even if they can just scrape a small set of sites, they can still hammer a site into the ground. One of the things I think Google has been doing really well since their start is knowing when to back of a site. So either rate-limit your clients, or back of a site if you see responses slowing down.
We just had a company hit one of our sites pretty heavily, and when asking them of back off a bit, they just asked if we could perhaps rate-limit them. Apparently they don't know how to reduce their traffic themselves.
Hey there! Founder of Browserbase here. If you're seeing any abuse from one of our customers we'd love to hear more. Mind sending more info to paul@browserbase.com?
Commenting because I can't get everyone's email; if you're reading this thread and would be interested in an automation engineering conference please email me at mailto:mail@cadocary.com
What about hybrid automations or human-in-the-loop flows? We have automations where the human starts by logging in, then hands over to the agent. Some parts may even be Puppeteer automated. This also means the session may be long running, typically for months at a time and the agent needs to notify the human again if they get logged out. None of the existing browser automation platforms I have tried make this easy or cost effective, so we are currently trying to build our own. Would love to consider Simplex if this is solved.
Could I ask why the flow starts with a human logging in? Is it because you're using their credentials and/or have some sensitivity around storing their credentials? Or is it something to do with 2FA (we handle 2FA)? Or are you just storing the session data after they log in so you can re-use it for those few months you mentioned?
Re: Puppeteer automation as part of the script -- we have a feature we wrote for one of our customers that we didn't promote to production where you can define a deterministic action in the dashboard that allows you to paste in JavaScript, but we're likely not to push that to prod anytime soon. Could you explain your reasoning for wanting to use Puppeteer still? We've generally seen customers fully switch over to Simplex instead of relying on their original Puppeteer/Playwright scripts -- since we have action caching, the underlying script (click on div locator with this div id, etc.) is pretty similar to what you'd get using Playwright.
Security conscious domain. We do automations on behalf of our clients and they don't want credentials stored. "Handling" 2FA automatically is completely unacceptable, it breaks the entire point of the 2FA security model. Besides, login sometimes involves out-of-band 2FA methods including phone number.
I can totally see the value of agent driven flows for automating flows that are highly dynamic, poorly specified, error prone, zero shot environments, etc, but that doesn't seem to be at all what you are demonstrating here. Maybe your demos could show something more "challenging" to automate?
As someone who has spent a LOT of my time in my career working on browser automation and testing, speed and cost was always key. Even with existing programmatic tools like selenium, playwright, cypress, etc speed and headfull hosting costs were already big issues. This seems orders of magnitude slower and more expensive. Curious how you pitch this to potential customers.
We've generally seen the "easy" flows not actually be easy. Workflows that have complex branching logic (shown when filling out the Aetna form in the first example in the video), structured scraping (the second example we showed in the video), and login/2FA/intelligent multi-agent scraping (shown in the last example in the video), are all things that are difficult to impossible to do with traditional automation libraries.
We also have an example of a complex, multi-agent workflow here that might be useful for you to look at: https://www.simplex.sh/blog/context-engineering-for-web-agen...
got it, I only looked at the website not the youtube video you posted above, my apologies. On the website, neither the billing platform demo nor the screenshots in the section below convey this value prop very well. Both sections show what appear to be trivial flows without explanation of some of the underlying complexities.
I suppose if you are hitting your target demographic dead-on with your marketing efforts, the value prop should be completely obvious to them, but still could be more explicit in your differentiation.
replying to myself here... I would be interested to see a more hybrid approach where an AI could step in to help retry / get past failures, or as a way of re-recording automation steps for a flow when something changes, but having AI in the loop for every action all the time feels wasteful at best.
Yep we actually cache flows after first run! This makes flows that are closer to traditional RPA pretty much the same as using Playwright/Puppeteer.
Great! I see that further down in the website, which I did not see before posting this comment. I think this could be valuable to demonstrate / communicate in the billing platform demo which is the first thing you see, and is what captured all of my attention (i never even scrolled down).
Edit: I just re-ran the demo and it seemed way faster this time??? the first time it said GOAL: PRESS_ENTER... (agent proceeds to think about it for 5-8 seconds) which seemed hilarious to me.
Sorry this may be a dumb question, why would you cache a flow?
Looks nice but that's a pretty steep increase from free trial to the lowest tier of 2500/month. Is there really nothing in between? Like a pay as you use plan?
Currently no, it's just the three options (free vs. $2500/month vs. larger enterprise plans). We do usually offer 2-3 month ramp up periods for the $2500/month plans that are usage based.
To be transparent, we're an early startup, and a big part of that is user validation. We've been lucky to have companies as small as 5 people sign onto our $2500/month plan -- it shows some commitment on their side and helps us understand whether it's a real problem for our users. That's the same reason the $2500/month plan isn't self serve (you have to talk to us first).
We're definitely thinking of adding a pay as you go plan! But we aren't there yet re: our understanding of the market, if that makes sense.
How are you different from Browserbase?
From my understanding, Browserbase mostly provides remote browsers for their users. We also provide remote browsers, but with a lot more infrastructure on top (single/multi web agents, caching/reliability support, an agentic IDE/editor, etc).
not really sure how that differentiates since those things you mentioned are ancillary to main value. Also - browser base is insanely cheaper, but looking at the prices this doesn't look like a real company mainly just a way to have users in free tier (with toy level limits)
We have paying customers in production at the Growth and Enterprise plans :)
What models are used ? and whether user data is used to train ? Not seeing privacy policy or TOS page.
Good questions! Will add these and put a data processors page tonight. We use Anthropic/OpenAI models.
Unfortunately, you're name-clashing with SimpleX: https://simplex.chat/
Homepage layout horizontally overflows <1000-ishpx wide to when it switches to mobile layout. Cool concept though.
Will fix, thanks for flagging!