Web automation
Glue between the tools you already run — pipelines, scrapers, dashboards and AI workflows that save real hours.
Every company past a certain size has someone whose week is partly spent moving information between two systems that do not talk. Copying orders into the accounting tool. Re-typing form submissions into a spreadsheet. Compiling the same report every Monday morning from four tabs.
That work is invisible on any org chart and expensive in aggregate. It is also usually the cheapest thing on this site to fix.
Where to start
We start with a short audit rather than a proposal, because the thing worth automating is rarely the thing people ask about first.
The question is simple: what does someone do repeatedly, by hand, from a recipe? If a task has clear inputs, clear rules and a predictable output, it is a candidate. If it requires judgement that changes case by case, it is not, and pretending otherwise produces a system nobody trusts and everybody works around.
We would rather automate three things properly than fourteen things fragilely. A brittle automation is worse than none, because it fails silently and someone finds out a month later.
What we build
Integrations. Making the tools you already pay for talk to each other — CRM to accounting, forms to database, storefront to fulfilment, whatever the actual pair is. Usually the smallest and highest-return work we do.
Data pipelines and reporting. Pulling from several places on a schedule, reconciling it, and putting the answer somewhere people will actually look. If the output is a spreadsheet someone reads on Monday, we build the spreadsheet, not a dashboard nobody opens.
Internal tools. The admin interface your team needs and your main product never got. Often the difference between a developer being interrupted daily and not.
Scraping and monitoring. Structured data out of sources with no API, competitor and price monitoring, availability checks. Done politely, with rate limits and an eye on what the source’s terms actually permit.
AI where it earns its place. Classification, extraction, summarising, drafting — genuinely useful for turning messy input into structured output. Less useful anywhere a wrong answer is expensive and nobody checks. We build the human review step in rather than pretending the model is always right, and we will tell you when a regular expression would do the job for a fraction of the cost.
How we think about it
Automate the recipe, not the judgement. The goal is to give people back the hours they spend being a data bus, so they can spend them on the parts that need a person.
Fail loudly. Every automation we build reports when it breaks — to a channel someone reads, not to a log file nobody opens. Silent failure is the main way this kind of work goes wrong.
Own it, do not rent it. These run on your infrastructure with your credentials. No per-seat fee to us, no dependency on us continuing to exist. Shortly, our own link tool, came out of exactly this instinct — every option we tried asked for more than the job was worth.
Leave it documented. A workflow nobody understands is a liability the day the person who commissioned it leaves. You get a written description of what runs, when, and what to do when it stops.
Working out whether it is worth it
The arithmetic is usually easy and worth doing before you commit.
Count the hours the task takes per week, multiply by the loaded cost of the person doing it, and multiply by fifty. Compare that to a one-off build. Anything above roughly five hours a week almost always pays back inside a year, often inside a quarter. Below an hour a week, it usually does not — and we will say so rather than take the work.
Add the errors. Manual data entry has a real defect rate, and the cost of a wrong number reaching an invoice or a report is often larger than the time saved.
What it costs
This is the most variable thing we do, and the one where a small budget goes furthest. A single integration between two systems with decent APIs can be a few days. A pipeline spanning six sources with reconciliation logic and an internal tool on top is a proper project.
The cost drivers are the same as everywhere: how many systems you do not control, how weird their APIs are, and how much has to be correct rather than merely usually right. The reasoning is in what a web app actually costs to build.
When we are the wrong choice
If an off-the-shelf tool already does it, buy the tool. We will tell you when Zapier and an afternoon would solve your problem, because a studio that builds you something you did not need has not done you a favour.
If you need someone embedded in your operations full time, you need a hire, not an agency.