[HN Gopher] Launch HN: Axiom (YC W21) - No-code browser automati...
___________________________________________________________________
Launch HN: Axiom (YC W21) - No-code browser automation a.k.a. RPA
for everyone
Hi all! We're Yaseer, Simon and Alex from Axiom. We've built a way
for non-technical people to automate work in their browser
(https://axiom.ai). Axiom lets you automate by recording actions
in the UI, like an Excel macro or Emacs, only it's for the whole
web. It can plug in to your APIs, too, to reach places tools like
Zapier can't. Gartner et. al. call this 'RPA' (Robotic Process
Automation), but we don't use this acronym with customers. I've
been a long-time HN lurker and occasional commenter. I decided to
do a Show HN 9 months ago with v1.0, and people seemed to find it
interesting: https://news.ycombinator.com/item?id=23089243. That
post was pretty transformative for us. We got our first users
outside our local network in London. We got shared on international
sites that syndicate HN content. We suddenly had users in Japan,
Korea, Denmark... eventually 111 countries in 9 months. The HN
audience were both usefully kind and critical. With our social
automations, you pointed out many violate TOS, and "your team needs
to do better" (ouch!). That didn't feel good at the time. But
later, we learned this is no way to build a business - battling
platform providers like LinkedIn does not scale. We learned our
value prop has to also benefit the platform we're automating.
LinkedIn automations - though widespread - don't do this. I think
we've achieved this with our use cases in e-commerce, like helping
Amazon sellers do repetitive data entry or report-generation on
their store. When we spoke to Amazon about automating repetitive
work for sellers, they offered to introduce us to more. Google's
algorithms eventually boosted us to 3rd on the Chrome store for
'browser automation', and Microsoft... added special code in Bing
to block us. This would have made us sad except, 2000 users later,
we have not yet found someone using Bing. Axiom has also evolved
significantly. The problems we're trying to solve with the DOM,
Ajax and messy web-apps are hard ones. Not deep-tech hard, but if
you've ever written a Selenium or Puppeteer script and tried to
write an algorithm to detect the end of page-load... it's not
simple. Since our Show HN, we've extended the library of algorithms
for more weird stuff you see in web apps: iframes, infinite
scrolls, drag-and-drop - there's a lot more to do. Web UIs are
complex; if Axiom doesn't work on a website, please let us know, we
improve our algorithms with every edge-case. Until recently, most
of our users were no-code enthusiasts (i.e. users of Zapier or
Airtable). They used Axiom in agencies to manage YouTube and Amazon
accounts. The dominant use-case was "generate reports by logging
into A, B, C and getting data". Since YC though, we've discovered a
bunch of developer and startup use cases. A very lightweight
automated testing tool is a new one - using Axiom is 10X faster
than writing it in selenium/puppeteer + we handle all the annoying
logic you need. We're investigating a Node library for this -
please let us know if it would be useful. Secondly, startups whose
business is 'we provide an API to do X' use Axiom to perform
whatever the 'X' is behind the API - e.g. booking on a travel
website. Although Axiom is primarily a Chrome extension, our cloud
product needs neither Chrome, nor an extension! It has a virtual
browser, with a full GUI, like you see in browser testing services.
You can run it 24/7, or trigger it from Zapier or your API. If you
build a bot on the desktop version, we'll guide you through setting
it up in the cloud. If you don't use chrome, and would like cloud
access, register here: https://axiom.ai/bot-building-service. Being
Chrome-only makes us worryingly dependent on Google - we definitely
will support other browsers after YC. Right now though, our small
team needs to prioritise fast iteration. We built Axiom on a
pretty popular framework, Puppeteer, which requires desktop
binaries to run. This means you need an Electron app, too. Trust
me, It hurts us more than it hurts you, supporting Electron on
Windows, Mac & Linux. This does make us one of the only cross-
platform RPA tools - Mac and Linux users have told us they
appreciate this. Our cloud product doesn't need any of this- but
it does mean we process your data. With our desktop app, your data
is processed 100% locally. We store the code which defines your
script, but not the data it operates on. Finally, the community on
HN is more influential than you may realize - taking interest in
our HN post changed the trajectory of our company entirely. Also,
we discovered responding to hard questions from smart people on HN
is pretty good prep for talking to investors, or a YC interview.
HN's interest was fundamental for us getting in. We'd like to thank
the community here. In fact, my first ever submission 4 years ago
asked (https://news.ycombinator.com/item?id=15098066), 'Ask HN:
what online communities offer a high level of discussion like HN?'
There's very few. It's a unique corner of the internet. If you run
into any issues with Axiom, please reach out to support - we're
very proactive at getting you running. Otherwise, please post any
feedback, ideas, questions or relevant experience - we'd love to
hear it again! Note: M1 Mac users, we have a workaround on our
support page for any issues. A hotfix for M1 is imminent.
Author : yaseer
Score : 114 points
Date : 2021-03-03 12:58 UTC (10 hours ago)
| TruthWillHurt wrote:
| https://www.selenium.dev/selenium-ide/
| yaseer wrote:
| Yes, selenium, and selenium IDE was definitely our original
| inspiration.
|
| (Aside, we built axiom on puppeteer though).
|
| I think Selenium IDE is primarily a developer tool.
|
| We see axiom as a no-code tool, following the same playbook as
| zapier and airtable - a 'no-code builder' whose ultimate goal
| is to create re-usable templates.
| [deleted]
| xrendan wrote:
| Is there any capability to run bots headless on our own
| infrastructure as opposed to locally?
| yaseer wrote:
| Yes there is! We do have an on-prem solution.
|
| What usually happens is someone builds a bot locally, and once
| it does the task they need, they talk to us about cloud and on-
| prem.
| xrendan wrote:
| Follow-up question, can I screenshot webpages that it visits?
| yaseer wrote:
| Not currently in the no-code interface! I've seen this
| requested before.
|
| Puppeteer (the library which runs our bots) does support
| this easily, so we may be able to whip something up if you
| have a sizeable use-case.
| xrendan wrote:
| I set up a meeting for tomorrow through your website
| (look for a meeting with Brendan), we've got a large use
| case for this and it could really help us out.
| yaseer wrote:
| awesome, we'll drop you an email too to understand more!
| troymc wrote:
| Does axiom.ai respect robots.txt restrictions or something
| similar (i.e. something specific to axiom.ai)?
|
| The reason I ask is that Joe Arbitrage could sign up for one paid
| premium account with a SaaS provider, then use that account and
| axiom.ai bots to provide the SaaS's services to a bunch of Joe
| Arbitrage customers at a higher price, i.e. customers who don't
| know about the original SaaS.
|
| Some SaaS providers wouldn't mind and offer APIs to do the same,
| but others _would_ mind, so it would be nice if there's a way for
| them to say "Go away" to axiom.ai bots.
| offtop5 wrote:
| Why couldn't this guy, or girl just program that directly in
| JavaScript instead of using this product. I don't see making
| browser automation easier as something which would enable bad
| people
| yaseer wrote:
| Certainly - we don't enable something to be done that
| couldn't be done before.
|
| We just make bot-building accessible to more people. Ideally,
| that means more helpful bots, but it could result in a more
| bad bots too, if we're not mindful.
| offtop5 wrote:
| Browser automation tends to be fairly easy anyway, I can't
| imagine anyone who wants to build bad bots only does so due
| to an no code solution.
| yaseer wrote:
| I think you're right, we just have a responsibility to
| kick those people off our platform.
| yaseer wrote:
| We aren't looking at robots.txt - but that's a great
| suggestion. It leads to a bigger point about bad actors.
|
| Unfortunately, people can build bots to do all kinds of bad
| things - this is something we have seen, considered and taken
| some steps to mitigate.
|
| Right now, we have a low level query, with follow-up manual
| inspection, to prevent bad actors. (Shout-out to our YC
| batchmates who alert us https://beta.useavenue.com/).
|
| For example, we detected bots being used for harassment on
| social media and stamped it out.
|
| It's possible for us to scale this up for similar 'bad use-
| cases' like the one you've identified.
| mattcrail wrote:
| Hey congrats Yaseer and team! Exciting to watch your progress.
| yaseer wrote:
| Thanks Matt!
|
| I'd love to reconnect after YC, the last few months have been
| fairly hectic, so apologies for dropping off the radar.
|
| I've been following your newsletter on https://taskablehq.com/,
| looking awesome!
| tartakovsky wrote:
| Regarding testing, that sounds like a great use case but I had
| trouble locating information on your website about it.
| yaseer wrote:
| This is a good point - we haven't put it in our marketing yet,
| the use-case is new. Here's a non-public landing page though!
|
| https://axiom.ai/automate-testing
|
| We also have this public recipe:
|
| https://web.axiom.ai/recipe/test-user-interactions
| Hitton wrote:
| I normally hate this kind of animations on websites, but in this
| case they look really good. (Only on the first page though, when
| I click on later pages, for instance "Bot Service", waiting for
| content to show is annoying.)
| alfiesmith wrote:
| Awesome glad you like the animations. I have made a note of
| your feedback; I will strip the page animations out of the
| nested pages. I still want to add a little something with
| animation and our branding to give the pages a unique feel, but
| something small and subtle.
| srwilliams1986 wrote:
| Thanks, noted! The crane is kind of our mascot at this point,
| he's been there since the very beginning (even when the product
| idea was quite different).
| jonbennett18 wrote:
| Have used axiom was very impressed with how easy it was to use
| and was capable of. I use as my own sort of zapier moving between
| some custom built stuff we have in work
| ccozan wrote:
| Hi, how do you compare your solution with UIPath? Thanks!
| yaseer wrote:
| Great question!
|
| We built axiom after running a software consultancy trying to
| integrate UiPath for customers.
|
| We realised, those solutions are great for $1 million
| consulting projects with a big development team. But most bots
| people need are small, and they need to be updated regularly.
| Paying for developers to do this is expensive.
|
| So, axiom is self-serve - it's designed to be built and
| maintained by non-coders on the ground (we provide support).
| Also, it's designed for the 0-$100 p/m small use-cases. There's
| lots of these in business.
|
| Some customers think we're expensive, but we're really not
| compared to most RPA, like UiPath :)
| brettfarrow wrote:
| Does Axiom support the ability to use network request data as a
| condition? I often test analytics integrations, and it's pretty
| repetitive to look at the query parameters or browser extensions
| for each one. It'd be helpful to automate tests based on whether
| a pageview generates a request to domain.com with param x=0, etc.
| yaseer wrote:
| We actually do look at network requests, but we only do this to
| assess page-load. Assessing this is a surprisingly hard-
| problem.
|
| I don't think our UI Testing tools monitor network traffic
| though. I can see how that might recur - if you email a test
| scenario to (my HN name) AT axiom.ai, we may be able to whip up
| some JS, that could be turned into a no-code block, for you and
| others to use.
| kettu228 wrote:
| Perfect timing, was just looking for something similar to this
| srwilliams1986 wrote:
| Awesome, let us know if you have any feedback, or if you need
| any help getting set up!
| Zaheer wrote:
| Curious about this use-case "booking on a travel website" - are
| companies using Axiom during a live request to book flight /
| hotels? What's the need for using Axiom vs using the booking
| sites API directly?
| srwilliams1986 wrote:
| There are two main ways this can happen:
|
| 1) There isn't an API, it's incomplete, or it's otherwise
| unsuitable. This is more true for smaller vendors, and less
| true for the bigger ones.
|
| 2) The company doesn't have engineering resource to fully
| implement an API solution, if it does exist. In this case
| there's somebody doing the manual process, and they are usually
| the one who actually implements the automation. This is the
| advantage of being no code! We've seen this a few times -
| people have been given the job of manually fulfilling requests
| and they decide they want to try automating it instead.
| yaseer wrote:
| Secondly, I obfuscated the example a little for the startup's
| privacy.
|
| They weren't booking something, they were cancelling something,
| and yes there wasn't an API.
| yewenjie wrote:
| Hi! Is there a plan for a Firefox version?
| yaseer wrote:
| Right now our desktop app is chrome only, but we'll expand to
| other browsers post YC.
|
| Our cloud supports any browser, we let you build a bot using a
| virtual one, like browserstack.com. As this costs us hosting
| bills to run, we do ask people to fill in this form, and we can
| set you up with cloud access: https://axiom.ai/bot-building-
| service
| ordinaryradical wrote:
| I used this product a while back to do some scraping of a very
| annoying (and slow!) to navigate website and it was a life-saver.
| Still using the google sheets it helped me generate. I saw the
| value of this tool straight away and the UI was pretty
| reasonable, just a few quirks.
|
| I would definitely use Axiom again if I ran into a similar need.
| Best of luck to your team.
|
| My one suggestion: Let people touch the UI and get a handle for
| building in a sandbox page on your site--a web app that simulates
| the app over your own site's dom, for example? I was hesitant to
| start my trial because 1) risk of hostile chrome extensions 2)
| wasn't confident I could learn the tool quickly enough. I think
| if you had a sandbox demonstrator on your site that let people
| experience the tool, you could learn a lot about where early
| users stall out and also build confidence toward sign-ups.
| yaseer wrote:
| Wow, that's awesome!
|
| What you've described is literally our cloud product - we give
| people a sandbox with a virtual browser to use and get started
| (like browserstack). We're working out a way to scale it
| cheaply, so anyone can get started. Right now, it's a paid
| feature.
|
| I'm very glad the feature we have planned is something
| customers would appreciate though, at least we won't have built
| something nobody wants. We made that mistake in the past...
| ordinaryradical wrote:
| Sounds like you're on the right track. I personally think
| codeless tools like these are all about confidence-building.
| I'm just technical enough to know what Puppeteer is and know
| how long it would take me to learn it. If I see that I can
| learn your tool right on your site/play around with it
| without having to sign up, my conviction goes way up.
| pimlottc wrote:
| The cloud feature sounds like a nice product, but I think
| ordinaryradial was suggesting something else (or if he
| wasn't, I am): a toy app on your own pages that also has the
| automation scripts "pre-injected". It would be limited to
| just running on that sample app but would let people try it
| out immediately in their own browser without needing to
| install an extension or use a full-blown virtual browser.
| yaseer wrote:
| Ah yes, I get the gist, perhaps I didn't explain, well.
|
| Creating that toy environment on a single page would result
| in us engineering something totally new, just for demo
| purposes (and it wouldn't be how axiom works).
|
| It's easier to just virtualise everything in the cloud, so
| you can see how it all works together. That way, we don't
| make anything new, we just virtualise what we've already
| built, and you can try it, instantly.
| ptrthomas wrote:
| > We built Axiom on a pretty popular framework, Puppeteer, which
| requires desktop binaries to run. This means you need an Electron
| app, too.
|
| I thought it was Playwright that depends on patched browser
| binaries and that Puppeteer works with stock Chrome and does not
| need Electron. Can you clarify, just trying to learn here.
| yaseer wrote:
| Yep, you're right!
|
| It doesn't need electron specifically, just several node
| modules that don't run in a browser-only environment.
|
| We use electron to package up the node modules, and use it for
| auto-updates + other 'nice' things electron can provide.
|
| I do hate how bloated electron apps become, and ours is also
| chunky. We'd like to slim this down with time, or perhaps move
| to a better framework.
| ptrthomas wrote:
| Thanks, that makes sense
| JoshuaLelon wrote:
| Neat! I feel like I have a reasonably good idea of what this
| does, but I'd love to see an example to make it really come to
| life.
|
| I see on the website you have a gif where you're setting up an
| automation.
|
| I'd love a similar gif (or set of gifs) where you have a before
| (ugh I have to do this manually), the middle (your current gif),
| and an after (axiom doing it automatically).
| yaseer wrote:
| You've hit the nail on the head for our biggest problem - many
| people don't realise axiom can solve their problem!
|
| We realised, the best way to do this is start producing
| templates with solutions to common problems. Here's one:
|
| https://web.axiom.ai/recipe/loop-through-pages
|
| As you say, visual guides work well. I think we have a lot to
| do here.
|
| We're gradually building up a library on the link above. One
| day, we'd like people to share their solutions openly (like
| airtable). We'd need to do security checks on our side though.
| ed wrote:
| I explored this idea last year and suspect this will be your
| main problem (people are bad at discovering automation use
| cases), unless you want to spend all your time fixing
| Craigslist scrapers. One possible solution is to keep writing
| these "templates", but publish them as Zaps, and ensure you
| rank when people google for solutions. I suspect the user-
| facing tool you have now could actually just be internal,
| used for writing as many zap automations as possible, to fill
| the gaps in Zapier's catalog. Use Zapier for distribution and
| find some verticals you can productize. Best of luck!
| yaseer wrote:
| Ha, you're pretty well versed in the pain-points!
|
| Yes, that's the playbook we want to follow - long-tail SEO.
| That worked amazingly well for Zapier, and if we had a
| cheesy tagline, it's 'plug gaps in your zaps' like you've
| suggested!
|
| One interesting side-effect we noticed - people take
| inspiration from templates for other use-cases and this has
| driven up usage.
|
| When we show a YouTube studio use case to one customer,
| they'll try do the same thing in Mixpanel.
|
| Starting a fire here may boil down to how many
| generalisable templates we can churn out, and how well we
| can train people on integrating them.
| reubano wrote:
| Who are your top competitors and how do you differentiate
| yourselves? Esp re recent HN submission
| https://news.ycombinator.com/item?id=26239975
| factsaresacred wrote:
| Add to that:
|
| - simplescraper.io
|
| - browserless.io
|
| - include.ai
|
| - apify
|
| - browseai
|
| In a way I suppose the high number of players in the market is
| validation.
| yaseer wrote:
| Indeed, there's demand/a market! Every player has a slightly
| different angle and market focus:
|
| -Simplescraper as the name suggests is very scraping focused,
| not process automation focused.
|
| -Browserless is more like 'heroku for browser bots' (i.e. a
| cloud runtime).
|
| -include.ai (having pivoted) are a tool for internal browser
| extensions.
|
| -browseai focus on the monitoring use-case.
|
| -apify are very cloud runtime focused (they price on the
| memory of their servers and are much higher than us - getting
| back into traditional RPA territory).
|
| ...speaking of which, I haven't even started on traditional,
| developer-centric RPA yet. For that there's obviously
| automation anywhere, blue prism, leapwork, electroneek...
| yaseer wrote:
| Here's a list of competitors and how I think we compare with
| each -
|
| UiPath - Designed for heavyweight Enterprise. We're really not
| competing for the same market, but their tech is a similar
| approach. They go for fortunate 500, we go for everyone else.
|
| Zapier - Axiom competes with zapier in some ways. We're
| different because we automate the Ui, not just APIs, and we
| integrate with Zapier.
|
| Automatio.co - They seem to emphasise cloud running, and their
| tool looks a bit more complicated. Most of our bots are
| actually used locally, where the user processes their own data.
| We support running in the cloud too. It looks like they're
| charging for distribution, where we're freemium.
|
| Phantombuster - They focus on templates, rather than 'build
| your own bot'. Also, nearly all social automations like
| LinkedIn.
|
| There will be more.
|
| Ultimately, I think browser automation will be similar to API
| automation, where Zapier, Tray.io et al, all compete with
| different approaches for different segments of the market.
| reubano wrote:
| Thanks for the synopsis. There definitely seems to new wave
| of automation tools coming out these days.
| smattiso wrote:
| Seems like Microsoft Power Automate (Flow) is your biggest
| competitor? It's free for all Office 365 users (most people).
| yaseer wrote:
| Yes, we've been monitoring Power Automate too!
|
| It's a different approach, coupled to automating the
| desktop office ecosystem, whereas we're coupled to web-
| apps, and web APIs alone.
|
| Secondly, it is more complicated, a bit more like Leapwork,
| whereas we're targeting Zapier-level complexity.
|
| Axiom is already too complex for many people (it's why we
| mainly target these no-code Zapier types). We've seen every
| marginal % increase in complexity reduces the number of
| people who can build bots significantly.
|
| Essentially, each RPA product has chosen a power vs ease-
| of-use trade-off for different segments. We're fixated on
| the Zapier / Airtable people, not the traditional desktop
| RPA people, whom I think Microsoft are targetting.
| finger wrote:
| I don't know if you can consider them a competitor but Kofax
| RPA, formerly known as Kapow Software / Kapow Katalyst is a
| powerful one I used many many years ago. I think the original
| product dates back to the 90s. You build a flow-diagram like
| process, with the possibility for a full suite of tools for a
| complete automation setup.
|
| I think this might be more catered towards enterprises. But
| from what I remember they had tools for everything, and making
| a bot for a website would only take a few minutes from start to
| finish.
| yaseer wrote:
| Ah yes, Kapow! This is like 'OG RPA' (...the technical
| definition)
|
| Many people forget that RPA is over 20 years old. UiPath
| basically took very old technology, modernised it, and re-
| applied it to new markets to become a $35 billion company (as
| of 2021).
|
| The OG Browser RPA solution is iMacros, incidentally, which
| is now 20 years old! We aim to also modernise what they tried
| to do and take it to new markets. I guess time will tell
| whether we succeed at that re-application, like UiPath did on
| the desktop.
| Sil_E_Goose wrote:
| >using Axiom is 10X faster than writing it in selenium/puppeteer
| + we handle all the annoying logic you need. We're investigating
| a node library for this - let us know if it would be useful.
|
| As someone who has recently started working with puppeteer, I
| definitely think a library to alleviate that pain would be
| immensely valuable.
| yaseer wrote:
| Interesting!
|
| If any puppeteer developers would also find it useful, let us
| know - it's always good to know something is wanted before you
| make it.
| dominathan917 wrote:
| As a developer about to go down the e2e testing pipeline for
| our new products and chosen puppeteer, I would also be very
| interested in this.
| loh wrote:
| I always hated writing e2e tests (tools like Cypress just
| didn't cut it for me), so I put this together a while back
| (it's open source, MIT licensed):
| https://github.com/testfront-io/testfront-devtools
|
| See also https://www.testfront.io/ for an actual description
| of how it works, but don't bother signing up. I'm really bad
| at marketing/getting the word out, and google took forever to
| approve the extension so I lost interest/ran out of money.
| Maybe if others show interest, I'll be motivated to resume
| the plans I had for it.
|
| Here's a 4 minute video of it in action, covering every user
| join/login/update possibility:
| https://www.youtube.com/watch?v=ifkaptIYeL8
| gvkhna wrote:
| We're building this at Superadmin, specifically for e2e
| tests. We're a little bit early but would love to collect
| feedback. Can we get you in as an early user?
| zild3d wrote:
| for anyone else about to go down the e2e testing road - I
| recommend checking out cypress.io
| yaseer wrote:
| Funnily enough, the first axiom prototype we sold customers
| was on cypress.io - I liked it!
|
| We switched it out for puppeteer as it was more suited as a
| library for our-case. Cypress is a great batteries-included
| E2E solution though.
___________________________________________________________________
(page generated 2021-03-03 23:01 UTC)