Before we started Anon, I spent several years focused on operations and workflow tooling for B2B teams. The recurring friction I observed wasn't about the software being bad. It was about a specific category of work that no tooling actually solved.
The pattern looked like this: an operations team had good systems, competent people, and genuine automation coverage for the parts of their work that touched modern SaaS tools with accessible APIs. And then there was another set of tasks, usually a significant fraction of the week, that was done manually because the systems involved were vendor portals, partner platforms, or compliance systems that simply didn't expose API access. These tasks ran on the same schedule as automated workflows, required the same kind of structured data movement, and followed the same repeatable steps. But they required a person because no tool could reach the system.
The Observation That Wouldn't Go Away
I kept seeing the same conversation at different companies. Someone would describe their automation setup with some pride: order management automated, CRM synced, reporting automated. Good coverage. Then they would mention, almost as an aside, that two or three people were still spending time every day on portal work. Pulling invoices from a carrier. Checking submission status on a compliance portal. Reconciling vendor data from a procurement system. The routine was clearly defined. The steps were known. But it was human work because the portal had no API.
The natural question was whether there was a tool that covered this. The honest answer was no, at least not at the right price point and deployment complexity for a team that wasn't running an enterprise IT budget. Enterprise RPA vendors had solutions in this category, but they came with implementation consultants, thick client software, and contracts priced for IT departments, not operations managers. No-code automation tools like Zapier explicitly couldn't reach systems without API access. There was a real gap between what was automated and what needed to be.
Marcus had been building browser automation infrastructure for years, first for enterprise data teams and then for various scraping and monitoring applications. He had a precise technical view on what was possible and what made browser-based automation reliable or unreliable over time. We spent several months working through whether the gap I was observing was real at scale and whether browser automation, built with the right infrastructure decisions, could cover it in a way that operations teams could actually rely on.
Why Browser Automation Is the Right Technical Approach
When a system has no API, the only way to interact with it programmatically is through the interface it does expose, which is a browser-based web application designed for human use. There is no shortcut here. You cannot reverse-engineer an API that doesn't exist. You can interact with the same interface a human user would, but execute those interactions reliably, on schedule, without the attention of a person.
The technical decision we made was to build on Playwright as the browser automation layer rather than on top of existing scraping or test automation toolsets. Playwright's async architecture, its handling of modern web application patterns including dynamic DOM rendering and network-dependent page states, and its native support for authenticated session management made it the right foundation for what we needed. The infrastructure we built on top handles session lifecycle management, authentication including MFA and TOTP, retry logic that distinguishes transient failures from deterministic ones, and the observability tooling that makes production operation practical.
We want to be honest about what this approach is and isn't. It is interaction with systems through their designed interface, not a bypass of their security or terms of service. The credentials used are credentials the operations team legitimately owns. The actions taken are actions those credentials are authorized to take. The automation replaces the manual labor of executing known-permitted actions, not circumvention of system controls.
The Decision About Who to Build For
We made a specific choice about the buyer. Enterprise IT organizations and large technical teams have options. The iPaaS vendors serve them. RPA vendors serve them. The gap we saw wasn't at the enterprise IT level; it was at the operations team level. The procurement manager at a growing company who manages 15 vendor relationships. The compliance coordinator at a mid-market firm who pulls regulatory reports from five different portals every month. The logistics operations team that runs status checks across three carrier systems daily.
These people don't have engineering resources to build custom integrations. They don't have IT budgets for enterprise platform deployments. But they have clearly defined, repeatable workflows that currently require their time to execute manually. That's the buyer we're building for, and it shapes every product decision we make: the deployment model, the pricing structure, the way workflows are defined and monitored.
What We Chose Not to Build
We made deliberate decisions about scope. Anon is not a general-purpose web automation tool. It is not a browser-based RPA platform for desktop applications. It is not an attempt to automate every possible class of browser interaction.
We focused specifically on authenticated back-office SaaS portal workflows because that is where the gap is most clearly defined and most practically valuable. The systems involved are web-based portals that require login credentials. The tasks involve structured data movement: extracting records, submitting forms, updating statuses, pulling reports. The workflows run on schedule or in response to known triggers. The constraint is always the same: the system has no API, so the only path to automation is the browser.
We are not saying browser automation is always the right answer. If a system has a usable API, use it. Webhook integrations are cleaner, more reliable over time, and easier to maintain than browser automation. Our approach covers the specific class of systems where that option doesn't exist at the access tier operations teams actually have.
What We're Trying to Get Right
The thing that kills browser automation in practice is reliability over time. Portals change. Sessions expire at inconvenient moments. Authentication flows add new prompts. The automation that works flawlessly in initial testing encounters these situations in production and fails in ways that require a person to investigate and fix.
The infrastructure investment we have made is entirely oriented toward this problem. Not just making automation work once, but making it work reliably over months without constant intervention. That means session management that anticipates expiration rather than reacting to it. Selector strategies that favor structural stability over implementation details. Retry logic that fails fast on deterministic problems and recovers gracefully from transient ones. Monitoring that tells you when something changed in a portal's layout rather than silently producing incorrect results.
We're a small team building a focused product for a specific operational need that the existing market leaves unserved. That's the honest framing of what we're doing. The gap is real. The approach is technically sound. The question we're working to answer is whether we can make it reliable and accessible enough to change how operations teams think about what's automatable in their workflow. We think we can. That's why we built Anon.
