
Show HN: Axiom – No-code Browser Automation - yaseer
https://axiom.ai/
======
yaseer
Hi all,

We built a way for non-technical people to automate work in their browser.
It’s in beta, and we’ve just made it public:
[https://axiom.ai/](https://axiom.ai/).

After running a consultancy, we noticed lots of small tasks that never got
automated. The cost was too high with existing consultancy-focused solutions.
So lots of small repetitive tasks built up.

Recently though, RPA has become a popular technology for automating big,
repetitive processes.

RPA (Robotic Process Automation) is a way to automate using the user interface
of applications, rather than APIs. If you’ve ever used an Excel or Emacs
macro, it’s the same principle. Companies like UiPath and Automation anywhere
have had great success deploying RPA for enterprise use-cases (e.g. processing
1000s of invoices for a multinational)

But we believe RPA also has potential as a no-code paradigm for smaller use-
cases (e.g a customer support person doing data-entry).

That's because most people intuitively understand UIs, but not APIs.

So we thought, what would happen if you took RPA technology and packaged it up
in a no-code Zapier-like SaaS? This way, all the small tasks too small for
developer time can get automated.

Our current users are mostly non-technical and in roles like sales or
e-commerce administration. They have repetitive extract, transform, load (ETL)
tasks, like:

-Gathering data for sales enrichment, then inputting into their CRM

-Connecting and exporting data from e-commerce systems like Amazon and Shopify, where APIs are limited.

UI-based automation is not just a way to fill gaps in APIs. We've found it is
a more intuitive and faster way for many non-technical people to automate.

Along the way, we’ve also discovered many new niches (like sports betting
funds) that we didn’t know existed.

Axiom is not built for large-scale data-scraping or automated testing, though.
These require specific features we do not yet support (e.g. IP switching, or
assertion logic).

We don’t touch your data. All data-processing and execution occurs client-
side, on your machine. We only store the code for execution. For data storage,
we use your Google drive account.

Our beta only supports Google Chrome (this is just an MVP. We want to expand
support to FireFox and other browsers with time and resources).

I’m sure the HN audience has seen how challenging browser automation can be,
particularly with the complexity of modern JS-heavy web-apps. We’d love your
feedback, experience and thoughts!

For example:

Some users have said the permissions being requested by our app are off-
putting. We’re listening and adapting. We’re removing permissions + improving
communication. To reiterate, we do not store any data processed by bots on
your machine: [https://axiom.ai/privacy-policy](https://axiom.ai/privacy-
policy)

~~~
virvar
As someone who implemented and runs RPA in the public sector I would be
interested if you made a couple of things come true.

No one offers an easy way to let employees build and share “personal” bots.
Part of this has to do with non-programmers having a much harder time
understanding things like loops than we imagined they would. Another problem
is maintaining business process logic and knowledge as employees come and go.
And lastly there is the security thing. In an enterprise setting you probably
won’t want to run this in someone else’s cloud, you want to run it through
your IT operations in your own onsite/cloud/whatever to both utilise your
local accessing rights but also to make sure data never leaves you.

Maybe we’re not who you are targeting, but we’ve yet to find a product that
actually lets us let employees build small bots in a way that fits into our IT
operations, and this is quite a big market in my country.

Of course you’ll be late to the table, and not be what the big consultant
agencies like EY are partnered with. But what they are currently selling isn’t
actually what we need.

So good luck, I’ll certainly add you to our “keep a look out” list.

~~~
productive
Virvar - out of curiosity - why is it that you would like to let the users
build those bots? Intuitively, users just don't have the skills, patience, the
technical mindset, the understanding of the IT landscape (imagine some non-
working SSO - which user is going to know how to get that to work!). Basically
"what's wrong" with doing it 'the normal way' \- which is to have an IT team
(in-house or external like EY) do the work?

~~~
virvar
We operate 300ish IT systems of various size, from handling vacation time
between leaders/employees to full fledged SAP solutions. We have 10,000
employees but only 5 developers of which 2 are also operations engineers
developers. If an employee needs a little bit to automate some small workflow,
to save them a few hours a week, that’s way below the scope of where we would
get involved to do an RPA process. But that doesn’t mean we don’t want people
to automate those tasks. In the ideal world we wouldn’t need RPA, because much
of what it does is things that should work smarter in our current systems. But
the enterprise world is far from ideal.

We didn’t use one of the big consultant houses like EY. We didn’t because we
have plenty of business process people, project managers and so on ourselves.
And that’s typically what the big consultants mainly offer, they offer it
along with tech consultants that are often from some partner. We started by
gathering info on what was available, as well as what we thought we needed and
we drew on experiences from other cities. Many places had gone with the big
consultant agencies and gotten this big package on the business end, and one
or two processes build with the tech consultant, and then their project
stranded because the business part doesn’t actually build RPA processes.

We decided to go with a small local startup, where we bought hours and “open”
consulting. We did brainstorms with them, but then we build things ourselves
and had them review it, and we put a much larger focus on learning the
technical parts - and well - we are now the leading city on this area if you
compare the 96 cities that aren’t our two largest cities. So from my anecdotal
view, that is far better than using the big consultant agencies.

I named EY, and that may give them bad publicity here, but EY was actually the
best of the big package offers that we didn’t decide to go with. Which is why
their name stuck with me, so it’s a little unfair if this makes them look bad.

~~~
productive
Thanks Virvar, may I follow up (and I am really just trying to understand
here, not to criticise or advocate one way or another): From what you said, I
understand that, essentially, 'the kind of steps or tasks that employees would
want automated' are too small for someone central to bother to look at. So
it's an issue of economics - it's not worth the attention and not worth the
cost. I fully understand.

On the flipside, you yourself mentioned a) the skill level (loops) and b)
maintenance and - dare I add - say governance / standards.

I guess it comes down to the tradeoff of [not having tasks automated because
it's not worth it for 'the experts'] vs [having a prolific ungoverned set of
automations deployed by users with insufficient skill level perform them (kind
of like excel macros)].

So given the skill issue, and given that users struggle with things like loops
etc. - does that mean that they'll basically just be able to implement
'trivial automations that don't involve complex paradigms'? Or how can non-
technical people, fundamentally, crack it and develop more elaborate (and
therefore more powerful) automations?

This is what I'm grappling with - I see so many no code tools out there, but
at the end of the day, you can only do very limited, not so valuable,
automations with them. Curious to learn your thoughts there.

~~~
virvar
This is the issue. The “no-code” + “no real oversight” tools don’t really work
for us, but we wish they did. ;)

~~~
productive
Alright -thanks for the clarification!

------
fancyfish
Happy Axiom customer here. Its main selling point: absolute ease of use. Like
a point-and-click selenium. Our analysts , who are doing quick analytics or
analytics without the need for a long-term engineered solution, are very
satisfied with it. I find it powerful enough for production use (it works with
IG and even FB to some extent).

Only downside I can think of: pricing is a bit opaque, outside the “desktop”
license.

~~~
yaseer
Hey, thanks!

Yeah, so pricing is opaque because in all honestly, we're still figuring
things out.

We're unlikely to lift pricing and annoy users. If anything, we're extending
the free trial for most users, and may introduce a cheaper tier too.

~~~
shireboy
Cheaper tier would be great. I can think of some things I could use this for
that are not 50$/mo things. Scraping personal finance, automating personal
blog etc. but I definitely understand a startup needing to figure out pricing

~~~
yaseer
Cool, by way of a quick survey on HN, how much would you pay in a cheaper
tier?

~~~
dotancohen
You're not asking me, but if home users are a target market then it would have
to be $1 - $3 dollars per month. I could imagine scraping local events
websites, banks, maybe online auctions, etc. When home users subscribed to one
or two services, we could get away with $10 monthly. Now, with home users
accustomed to $1 apps and subscribing to a dozen different services, $3 is
about the maximum before signups drop significantly.

~~~
soneca
I would say it is impossible to make any business model work charging $1 to $3
per month.

~~~
vntok
$3/mo is $36/year, most templates on themeforest and other platforms are
around that price and they are selling fine. Considering the code is running
on the user's side, the marginal cost for low-tier customers is probably
minimal.

------
eastendguy
Hi, interesting. Does this run in the browser or on the backend?

"All your bots live on you computer and process data in your web browser. We
store the steps of your bot and data"

It seems the scripts are stored on your servers? Why? Does this mean that you
can see my code or is it encrypted?

How does this compare to the more established web macro recorder tools
(browser extensions) like the open-source kantu?
[https://github.com/A9T9/Kantu](https://github.com/A9T9/Kantu)

~~~
yaseer
Good questions!

This currently runs only on your local machine. We do have a cloud version
coming soon, but running your bots this way will be optional.

Yes, the code only is stored, not the data it processes. We could encrypt them
so we can't read, but it would prevent us updating your scripts in future for
new versions of axiom.

It does mean we could run your code, but this is not something we do, unless
you want us to run your script in our cloud.

UI.Vision and long-established macro-recorders like iMacros target developers;
this is a complete no-code approach.

Our tool is primarily built for non-technical people. We also have and are
building up a bot sharing system (i.e. templated bot app store). It will be
subject to manual vetting for quite a while.

~~~
gt50201
In a previous company we were scraping customers web pages to load customer
and product information because the number of systems and teams involved to
connect to their CDP would take months to get up and running. A few problems
we had to solve was the web pages changing underneath us and some pages not
being formatted the same. We ended up having to detect those changes server-
side to alert us to update the scraper. How do you all deal with these use-
cases?

Also, we tried to leverage:
[https://www.diffbot.com/](https://www.diffbot.com/) but the lack-of-
accuracy/lack-of-complete-data + cost never justified it's usage.

~~~
yaseer
Yes, very good question (I've answered a similar one on detecting whether the
page has finished loading).

It's a deceptively hard problem. Essentially, what we do is fingerprint the
element. If the page changes, it boils down to how effective our
fingerprinting and search algorithms are, to find the element if it has moved
or changed.

The algorithms behind that are good enough for most use-cases now, but it's
something we're continuously iterating on.

------
jhunter1016
I think for anyone who has ever tried to do significant scraping, or even
testing, with something like Puppeteer, you can easily see what services like
this should exist. The price is surely targeted towards businesses, and I
think that's a smart move.

------
dan-robertson
I saw an old demo from Microsoft research in their programming by example
group. The idea was to figure out how to extract (json-shaped) data from
websites given a few examples of where that data was by the user. The video on
this site reminded me of that. I think this presents a better interface than
MSR and by restricting to tabular structures of data (as far as I can tell), I
think the system is easier to understand and likely more reliable.

~~~
yaseer
We do indeed restrict ourselves to tabular structures of data, both on the
web-page level and outside.

Many non-technical people think in terms of spreadsheets and tables. If you
give people the spreadsheet/table as the data structure primitive through
which you're iterating, they get the concept of a loop straight away.

Couple that concept with teaching them a variable, and they can achieve a lot.

~~~
dan-robertson
I think a tabular model is probably a good idea

------
voldemort1968
Looks like a great tool, but $50/month is pretty steep especially when I'm the
provider of the computing power. Can you explain the rationale behind this
price?

~~~
yaseer
Yes, we decided to start high, and introduce lower tiers after, because
lowering your prices doesn't upset people, but putting them up does.

Many of our users are expecting to pay $50 p/m, but will get a present
surprise of a cheaper tier this month, rather than the other way around.

~~~
rasabatino
AS someone who is the core demographic that will use this: if this works the
way it says it does, it could cost $100 and I would still expense that to my
company without blinking.

------
wackget
I really like the concept, having personally struggled with browser automation
scripting in the past for business and personal use.

However, I'm concerned about the privacy and security implications of storing
users' automation scripts in the cloud. What if I want to automate processes
on sites or applications which contain sensitive data?

In other responses I think you've confirmed that scraped data itself is never
sent to your servers, but even the script and its metadata (e.g. names of
fields, search terms, IDs of elements on the page etc.) can contain sensitive
information.

In several of my clients' environments the use of this tool simply wouldn't be
allowed because no third party data is allowed to leave the internal network.

Is there a way to use the product without sending _any_ data whatsoever to
your servers?

Also, does this work with browsers other than Chrome?

~~~
yaseer
This currently only works with Chrome (still an MVP). We would eventually like
to expand support to other browsers with future iterations.

RE: Data leaving the network.

This is a very good point.

If you have a strong business-case you'd like us to look at, but find privacy
is the main issue, e-mail me at yaseer AT axiom dot ai; we may be able to
investigate what on-prem would look like.

------
rvz
> Axiom is quick to use; just point and click, with no need for API
> integrations or complicated code. Get bots running fast and spend more time
> on the important stuff.

Great and it gets to the point for the end users. But..

> Step 2 of 2 - Install the desktop application.

> 168 MB for the DMG, 427 MB for the app.

I get that this is your first release but is it possible that the Chrome
extension can be used on its own? If not is it possible to reduce the size of
this app? I say this because my impression after opening this app is that it
will be running in the background which will take up more of my Macbook's RAM
given that it is Electron.

On top of that, I already have 11 other Electron apps installed and this one
is twice as big as three other electron apps I already have and my disk is
already complaining about freeing up space.

~~~
yaseer
Yes, we definitely want to eliminate the electron app. I agree they are
bloated and annoying.

The first route for this is running your bots in the cloud, although that will
mean we have to process your data (something we don't currently do).

We do want to release a stripped down version that can run with the extension
alone, however, this won't support many of the most common use-cases for
axiom, like bulk downloading and uploading files.

------
msla
Sounds like something similar to the PawClaws project:

[https://chrome.google.com/webstore/detail/pawclaws/figeaallb...](https://chrome.google.com/webstore/detail/pawclaws/figeaallbafpdefmmkfipkgdgpknmhfl?hl=en)

[https://github.com/TobiasKundig/PawClaws](https://github.com/TobiasKundig/PawClaws)

[https://github.com/PawClaws/chromePawExt](https://github.com/PawClaws/chromePawExt)

I wonder though: How do you deal with asynchronous sites which may take a
variable amount of time for elements to load? Do you synchronize with Angular
or try to detect elements or is it just the old stopwatch-and-pray technique?

~~~
yaseer
Very, very good question. The long-story short is that I don't think there's
an algorithm that can determine the completion of page-load with certainty for
complex JS SPAs.

We fingerprint elements, check if the page is changing along the critical path
and wait if it is, and look at network traffic.

We can't say with certainty, but we can form a good guess - the accuracy of
that guess is always improving.

This is something I think would benefit from open-source collaboration, if we
went down that route.

------
iwangulenko
Web scrapping is a huge problem and I am happy to seem more usable solution
but why do you need these permissions from me:

See, edit, create, and delete ALL of your Google Drive files

See, edit, create, and delete ALL your spreadsheets in Google Drive

~~~
bkanber
Google Drive and Google Calendar permissions are not that great. IIRC there is
no distinction between individual CRUD actions, so if the app wants to create
a file they also need perms to edit and delete.

------
wheelerwj
hey @yaseer, Really cool idea, thanks for sharing! RPA is a great, underserved
niche for the SMBs.

I've read through your privacy policy but i'd like some more clarification.

specifically, can you talk about exactly what data is sent to your servers?
For example, if i use Axiom to login to a vendor site, those log on
credentials should be stored only locally correct? Does your team have the
ability to access any of the data that would be retrieved from the vendor
application? I have a few really solid use cases but I need to cover the data
privacy concerns first.

~~~
yaseer
Yep, of course.

That's right; Right now, we don't store credentials.

The cookie from your local machine when logged in is passed to axiom locally,
and never sent to us.

We store the code for your script on our servers. This is necessary to update
scripts for future versions of axiom. We do not store the data this code
processes.

We do have a cloud version upcoming that will process data on our servers, but
this will be optional, and not enforced.

~~~
wheelerwj
Thanks, for example, you would be able to see the steps of the automation, and
the site (full URL) where the automation is targeted, the name of the fields
being captured during scraping, and you might receive some data about the
success of the step/process. But you do not receive any feedback about whats
gathered or returned to the desktop.

Cloud version could be cool for some people but i think it might kill any shot
at the industry I serve.

~~~
yaseer
Yes, that's exactly right - we would see the URLs, the names of fields (from
the DOM), and success states.

Just not the data itself. It's basically what would be stored in a web-
scraping or automated testing script.

------
dmix
I could see this being useful for tracking COVID data on government websites.
Ontario only posts the current days stats for 24hrs until the next day. You
could extract it into a spreadsheet with this.

I'm also curious if there are some use-cases for tracking releases of new
content on various sites, similar to how CouchPotato combines TV show releases
and tracking them on torrent sites.

~~~
yaseer
We've thought about this too! It's not really effective with our desktop
version.

The cloud version should enable it though.

One of the most common things people want to do is create a series of bots
than consolidates data and generates reports; it has general applicability for
use-cases outside COVID.

------
iudqnolq
The promo video includes "Click Social Media Buttons: This bot only clicks on
the social media button if it has not already been liked or followed" [vid]. I
can't think of the intended use case; how do you envision this might be used?

[vid]:
[https://youtu.be/D3dqsZ1fyCU?t=112](https://youtu.be/D3dqsZ1fyCU?t=112)

~~~
yaseer
In private beta, a lot of users were using axiom to automate their likes and
follows, to build up an audience on Instagram. They were doing this work
manually in any case.

We would not want this to be done at scale, in a cloud, like a nefarious bot-
farm. However, at the scale of a bot tied to a single individual's browser,
doing repetitive work in growth-marketing and sales, we'd allow this usage.

~~~
michaelmior
Isn't this a violation of Instagram's ToS?

~~~
yaseer
[https://help.instagram.com/1188470931252371](https://help.instagram.com/1188470931252371)

Creating user accounts with bots, and crawling certainly is, but I can't see
anything about automating likes (correct me if I'm wrong).

There are many chrome extensions which do specifically automate likes on the
Chrome store. Ours is just a chrome extension for general browser automation,
where this is just one use-case.

~~~
fenwick67
"We prohibit crawling, scraping, caching or _otherwise accessing any content_
on the Service via automated means"

...

"You must not create or submit unwanted email, comments, likes or other forms
of commercial or harassing communications (a/k/a "spam") to any Instagram
users."

~~~
yaseer
Okay, I agree this a grey and perhaps questionable area.

This seemed to be something legitimate people/users were doing a lot, so we
gave them a building block to make it easier. Maybe we should have thought
about it more.

We'll take a step back from that path if our bots become a nuisance on social
media. In all honesty, we built axiom with other things in mind (e.g.
Repetitive data entry and admin).

~~~
alwayseasy
It's not grey it's a TOS violation. Facebook goes after these types of bots
ruthlessly, especially in election season. I'd recommend not poking that bear,
you have so many market opportunities!

~~~
yaseer
Okay, we'll take this on board!

It was honestly just some user requests we integrated without enough thought,
not something nefarious. This isn't our market by any means.

------
jonny383
Why is your product called Axiom "AI"? I'm struggling to see any actual AI
baked into the product.

~~~
gas9S9zw3P9c
I had the exact same thought. I would suggest to take out the .ai because it
IMO makes you look disingenuous. If your name is already clear marketing BS,
then someone may extrapolate that to the rest of your product.

That happened to me, you already lost credibility with me by naming it .ai
because, in my mind, you either 1. Have no idea what AI means, or 2. You know
very well but you are lying.

I'm not saying either of those are true, but that's what was going through my
mind when I first opened the website.

~~~
arethuza
I really don't see what the problem is with the choice of domain name.

Looks like a useful tool that I'll definitely have a play with.

------
vongomben
Gonna check this tomorrow. Lately I had big pleasure using nbrowser node in
node red [https://flows.nodered.org/node/node-red-contrib-
nbrowser](https://flows.nodered.org/node/node-red-contrib-nbrowser)

------
anandchowdhary
Really exciting to see this! My friend and I are also working on a very
similar open-source SaaS offering, Puppet [1], so much so that we use the same
"no code browser automation" words to describe our service.

When we launch in the coming weeks, I'll be sure to post on HN, but in a
nutshell, it's entirely cloud-based (as opposed to having to downloading
something), open-source, and at a price point closer to ~$5/m.

Of course, Axios is a far superior product with many more features, but we're
targeting individuals who want to automate small parts of their workflows
rather than businesses who'd pay $50/m.

I'm glad to see your launch and I'm sure there's plenty of room to play. :)

[1] Very under construction landing page (all hash links) for the extra-
curious: [https://puppet.js.org](https://puppet.js.org)

~~~
johns
Congrats on nearing launch. You’re being downvoted because it’s socially
unacceptable here to use a competitors thread to promote your service. Unless
you are specifically mentioned by another commenter or you have a broader,
vendor-agnostic insight to provide related to the service, you’ll be better
off discussing your service in your own submissions about it. Good luck with
the launch!

~~~
anandchowdhary
Got it, thanks for letting me know!

------
shakermakr
I see this is sponsored by SAP. Is it integrated with their existing RPA
offerings?

~~~
yaseer
We're a startup from SAP.io's accelerator program, so quite a separate entity.

We received funding/mentorship from SAP via Techstars, but don't integrate
with their RPA (right now at least...).

SAP's RPA is more focused on larger enterprise use-cases within their
ecosystem, whereas we're looking at SME and even consumer use-cases.

------
xrendan
How easy is it to customize data output? If I have a JSON Schema I want to
conform to that requires collecting data from multiple linked pages, is it
possible to do that?

~~~
yaseer
It is possible - but you'll need to write code.

Right now we have a custom code-block with a gloriously undocumented API.

I recommend playing around, seeing if you think axiom is useful for you, then
dropping our support an e-mail on ai AT axiom.ai and we can talk you through
the rest of your use-case. We're pretty responsive.

------
levpopov
Congrats on launching! yaseer, why does Axiom require a desktop app (vs
running purely as a chrome extension)?

~~~
yaseer
We found a whole set of technical limitations to using just a chrome extension
(file downloads and uploads to name but one). The simplest solution was to
include a desktop service, although I agree it's a huge inelegant electron
app.

This paved the way for running axiom in the cloud. Once we can do that, you
won't need the desktop app.

I hope with time we can have a slimmed down extension-only version too, but
this will be more limited in capability.

------
oredbored
You mentioned sports betting funds - Just wondering if you could elaborate
further on the use case here?

~~~
yaseer
Collecting and consolidating data + filling in the forms across different
sites to place bets

------
wheelerwj
also, there's no download link on your tutorials/help page. kind of a growth
hack fail.

~~~
yaseer
Very good point. There is now.

------
marc_io
This looks quite similar to Ghost Inspector.

------
polskibus
Any plans for open source for on-prem use ?

~~~
yaseer
Right now it's actually entirely on-premise, as bots run only on your local
machine - we don't process data.

Open-source is something we'd definitely consider - there are many hard
technical problems with browser automation that would benefit from open-source
collaboration.

~~~
yaseer
Correction -it's not entirely on-premise. The script storage and login is tied
to our server.

This thread has given us some serious thoughts about a fully on-premise
version though!

------
ronack
Reminds me of Ghost Mouse from 20 years ago. I remember using it to automate
Connect Four and win a few bucks from iWon.com.

