Most companies hand their most repetitive work to their most capable people. Someone who could be closing deals spends the morning copying phone numbers into a spreadsheet. Someone who could be fixing the product spends Friday afternoon restarting containers by hand. The work isn't hard. It's just long, and it wears people down.
Repetitive task automation solves a narrow version of that problem: the parts of a job that follow the same steps every time. I write the script that performs those steps so a person doesn't have to. Every project I've delivered ended with the same team doing more interesting work, not a smaller team.
Where repetitive task automation actually pays off
Not everything should be automated. A task is worth the build when it's predictable, when the rules rarely change, and when someone performs it often enough that the setup time pays itself back. Three examples from projects I've delivered.
Web scraping for lead generation
A real estate team was collecting property owner details from several listing sites by hand. Each lead took two to three minutes to find, copy, and tidy. Across a full list, that came to six or seven hours a day of someone's time.
I replaced it with a scraper — a program that opens web pages the way a browser does and pulls specific fields out of them. It:
- walks through listing pages on its own, following pagination
- extracts the fields the client asked for: name, phone, price, location
- writes each record straight into a database, instead of a spreadsheet someone has to merge later
The same job now runs in the background and finishes in under thirty minutes.
Server management and deployments
A small SaaS team was updating their servers manually: pulling the latest code, restarting Docker containers — Docker packages an application with everything it needs to run, so it behaves identically on every machine — and fixing environment issues by hand. Steps got skipped. Sometimes the service went down mid-update.
I wrote a deployment script that connects to each server, pulls the current code, rebuilds the services, and restarts them in order. Deployments became faster and more consistent, and almost nothing in that process is done by hand now.
Automated data entry between systems
One client had staff copying records out of one internal system and into another all day. Nothing about it was complicated. It was the same handful of steps, repeated thousands of times.
The automation I built reads records from the source system, fills the forms in the destination system, and cleans the predictable text problems on the way: trailing spaces, inconsistent capitalisation, phone numbers stored in four different formats.
It runs unattended, around the clock. The team's job shifted from doing the entry to reviewing the cases the script flags as unusual.
What exception handling looks like in practice
A script that stops dead at the first surprise is barely better than no script. Mine log the record that failed, the reason it failed, and the state of the page at that moment, then carry on with the rest of the queue. You get a short review list at the end of a run instead of a job that died at 2am on row 400.
The stack behind python browser automation
Recorded macros — the kind where you press record, perform the steps, and save — tend to break quickly. They assume the screen looks exactly as it did on the day you recorded. Here's what I use instead, and when each one fits. The full breakdown lives on the <a href="/automation">page describing my six automation service lines</a>.
Python and Playwright
Most of my work is Python. For anything involving a real website I use Playwright, Microsoft's browser automation library, which drives an actual Chrome or Firefox. Because a real browser is doing the work, it handles logins, JavaScript-rendered content, and pages that only load their data once you scroll.
Sites with bot protection need a stealth setup: a browser configured to look like an ordinary human visitor rather than an automated one. That takes longer to build and runs more slowly, and I'll say so before the build starts rather than after.
No-code and AI-assisted options
Plenty of jobs don't need a Python build. For simple, stable workflows I use UI.Vision RPA, a browser macro tool that records and replays steps without code, or Automa, which chains browser actions into a visual workflow and can call an AI model mid-run to interpret a messy page. These cost less to build and you can edit them yourself. They're also the first thing to break when a site gets redesigned.
Chrome extensions and userscripts
When the automation needs to live inside a browser someone already uses — a button on a page, a panel that appears on one specific site — I build it as a Chrome extension or a Tampermonkey userscript, which is a small program that runs automatically on the pages you visit. These suit tools a team triggers by hand, rather than jobs that run on a schedule.
Where the data lands
A scraper that produces nothing usable isn't finished. Repetitive task automation only counts once the output arrives somewhere the team already opens: CSV, Google Sheets, Airtable, SQLite for a single-file local database, or PostgreSQL once the volume justifies a proper server. If you already run a system, I connect to it through its REST or GraphQL API, or push results to a webhook as they arrive.
Scheduling is part of the build, not an afterthought: hourly, nightly, or event-triggered, with retries when a page times out and a queue so a long run doesn't collide with the next one.
Terms of service and robots.txt
I'll tell you how a site can be accessed technically. Whether you should access it is your decision, and it turns on that site's terms of service and its robots.txt file, which lists what automated visitors are asked to leave alone. I'd rather raise that before a build than after one. Where a site publishes an official API, I'll usually point you there first — it's more stable and it's cheaper to maintain.
Getting custom automation scripts built
I work alone. You can read how a one-person build process works, and I sell through Fiverr only.
What I need from you: the site or system involved, the fields you want, where the output should go, and how often it should run. What comes back: the working automation, a plain-English note on how to run it, and the output in the format you asked for.
If you have a task in mind, send me the details of the job. If you'd rather read more first, I write up other builds in my automation project notes.