Hacker Newsnew | past | comments | ask | show | jobs | submit | marcon680's commentslogin

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.


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.


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?


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 :)


Will fix, thanks for flagging!


Good questions! Will add these and put a data processors page tonight. We use Anthropic/OpenAI models.


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.


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. :)


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.


Thanks John! We should make that more clear in the docs. You can set browser=None on initialization and Simplex will create a local browser instance that can run on your local websites. We're not planning to be open source right now since a large portion of our product is custom vision models + inference speedups through hosting.

Browser Use is another YC company. Probably the biggest difference is that they're more agent focused while we're more lower level -- in the Claude Computer Use camp like you mentioned.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: