Browser automation for no-API systems
Stop paying people to
click through systems with no API.
I build browser automation that runs the portal and back-office web work your team does by hand, in the sites and systems that never gave you an API, then keep it running when those sites change. Built on Microsoft's stack, by one engineer who stays accountable for it.
No API. No budget for enterprise RPA. No off-the-shelf fix.
The work that drains a team is repetitive, rule-based, and stuck behind software that was never built to be automated. Here's why it stays manual.
There's no API
The portals and tools you depend on weren't built to talk to anything. So the work falls to people: log in, look it up, copy it out, paste it somewhere else, repeat. All day.
It caps what you can do
Every record is somebody's minutes: log in, key it, check it twice. It doesn't scale, it stalls the moment someone's out, and every hand-off is a place errors slip in.
Nothing on the market fits
Enterprise RPA is priced for big companies and takes months to stand up. Offshore teams can't go near your systems or sensitive data. You need someone who can build it and own it.
Built around the work your team repeats, not a generic bot.
Automation lands where the same steps happen on every record. Almost all no-API work is one of three shapes.
Look-ups & status checks
Pull records, statuses, and documents out of a portal that makes you search one at a time, so your team stops doing it by hand and gets a clean batch back with only the exceptions flagged.
Data entry & publishing
Push records into a system or site that has no API, keyed exactly the way a person would, with validation and retries when something doesn't take the first time.
Re-keying between systems
Move data between tools that don't talk to each other, so nobody's copying off one screen into another and reconciling the two by eye.
Plus the rest of the repetitive web work: downloads, form-filling, exports, monitoring for changes. If a person does it the same way every time, it's a candidate.
Assessment, build, then managed. Because this needs upkeep.
Browser automation breaks when portals change. A service that's maintained is worth far more than a script that isn't, so the engagement is built that way from day one.
Assessment
A focused look at your workflows with your real numbers, and a straight recommendation on what to automate first, and whether it's worth doing at all.
Build
I build, test, and launch the automation in your environment. Credentials and sessions held securely, dedicated service accounts, nothing running off someone's desktop.
Managed
I run it, monitor it, and keep it alive as the sites it touches change, plus support and ongoing improvements. That upkeep is the service, not an add-on.
12-month minimum term, which keeps the build affordable up front. Figures are typical ranges, not a binding quote.
I've built no-API automation that erased years of manual work.
Two production systems: one pulling data out of platforms that hoard it, one pushing data into sites that won't take it. The same pattern behind almost any no-API system.
From manual googling to 47,000 facilities
Employees googled assisted-living facilities one at a time and guessed at emails. Impossible past a few hundred records. I built a pipeline that collects records from government sources, enriches each through Google APIs, and validates every email for deliverability. No human in the loop.
1,000× publishing output, zero hand-keying
Hourly staff hand-keyed fund performance data into 30 partner sites that had no API. Every typo was a credibility problem, and every departure meant retraining someone on all 30. I built a cloud pipeline that logs into each site and publishes through the browser, with retries and zero-downtime deploys.
Security and terms of service, handled out loud.
The reason most people won't touch this work is the same reason it's valuable. Here's how I handle the parts that matter.
Runs in a hardened environment
Credentials and sessions live in Azure Key Vault on dedicated service accounts, not on a staffer's laptop, not in a spreadsheet.
Your data stays where it should
I scope every build to the minimum data it needs and work inside your security posture, not around it. Sensitive data and systems stay in your environment.
Site terms, on the table from day one
Some sites restrict automated access in their terms. I'll raise that before we build, not after. It's a decision we make together, not a risk I hide.
A translator between how the work gets done and modern automation.
Most automation help is one of two things: a big RPA vendor that doesn't understand your floor, or a developer who's never sat with the people doing the work. Both leave you doing the translation yourself.
My background runs through aerospace, manufacturing, fintech, and healthcare, and through C#, SQL, Azure, and browser automation. I speak the operations side and the engineering side, which is exactly what no-API automation demands: someone who gets the workflow and can build the thing that replaces it. It's a rare combination to find in one person you can actually hire.
Let's find one workflow worth automating.
Fifteen minutes. Bring the workflow that wastes the most time, and I'll tell you honestly whether automation pays, before anyone commits to anything.
Founding clients (first three): build fee waived in exchange for a documented case study and a reference call.