Automation
Automation is useful when a human is doing the same digital task every day: portals without APIs, pricing checks, form submissions, hand-offs between tools.
Anybot is this category: Playwright, scheduling, recovery and logs — so the workflow is observable, not a fragile script on someone’s laptop.
The failure mode of most automation is a script that works once and breaks the next time a page's markup changes, with nobody noticing until someone asks why a report did not arrive. Anybot's workflows are Playwright sequences — navigate, fill, click, extract — run against a real headless browser, so JavaScript-heavy sites a simple HTTP scraper cannot handle still work, and a log viewer records which step ran and what it did, so a failure traces to the exact step instead of a blind re-run.
Scheduling and error recovery are built in rather than bolted on: a workflow runs on a timer without anyone triggering it, and a single failed step does not require re-running the whole sequence. Webhook notifications tell other systems when a task finishes or fails, so automation plugs into whatever the team already uses instead of becoming its own silo.
Not everything should be automated. If a task changes shape every time or needs real judgment, I will say so rather than build something fragile that looks automated but needs constant babysitting.
Business problems
- A human logging into the same portal every day to run the same form submission or price check, because no API exists for that source.
- A one-off script that worked once and now fails silently every time a page's markup changes, with nobody noticing until a report does not arrive.
- Automation that runs with no logs, so a failure means starting the investigation from zero.
- A browser automation script running on someone's personal laptop, so it stops the moment that laptop is closed, asleep, or the person is on vacation.
- No alerting when a workflow silently stops running, so weeks can pass before anyone notices a report stopped updating.
- A workflow that assumes a page always loads instantly, so it breaks the first time a target site is slow, and there is no retry or timeout strategy to absorb that.
- No rate limiting on the automation's own requests, so it can look like an attack to the target site and get the account or IP blocked.
Development process
- Define the workflow as a sequence of browser steps — navigate, fill, click, extract — run against a real headless browser with Playwright.
- Add scheduling, error recovery and webhook notifications, so the workflow runs unattended and other systems know when it finishes or fails.
- Ship a log viewer that records which step ran and what it did, so a failure traces to the exact step instead of a blind re-run.
- Run workflows on a server, not a laptop, so they execute on schedule regardless of who is online or which machine is turned on.
- Alert on silence, not just on failure — a workflow that should run daily and has not run in two days is itself a signal something is wrong.
- Add explicit timeouts and retries with backoff for every network-dependent step, so a slow page or a flaky connection degrades gracefully instead of crashing the workflow.
- Throttle the automation's own request rate to look like reasonable traffic, not a burst that gets an account flagged or an IP blocked by the target site.
What you get
- Hundreds of manual tasks automated and observable instead of running silently on someone's laptop.
- Zero-touch operation after setup — the workflow runs on schedule and only surfaces when something actually needs attention.
- A workflow that keeps working when a target site changes something small, because failures are visible and traceable instead of silent.
- Workflows that keep running whether or not any specific person is online, because they live on infrastructure, not a laptop.
- Problems surfaced by an alert on missing runs, not discovered weeks later when someone finally asks about a stale report.
- Workflows that tolerate a slow or flaky target site instead of crashing the first time a page takes longer than expected to load.
- Automation that stays under the radar of basic bot detection, because request patterns were designed to look reasonable, not like an attack.
Selected projects
FAQ
Is this RPA?
Similar outcome, different shape. I build targeted automation with code, queues and monitoring rather than a heavy RPA suite unless you already have one.