from $2,400
The repetitive path between your systems
Built once and handed over with documentation a person on your team can read and change.
Most businesses run for more hours than they are staffed for.
We build the automations and assistants that carry the work through those hours. Then we stay on and operate them, because software nobody is responsible for stops being an asset within about a quarter.
The same details get retyped into three systems before anyone touches the actual work.
The first hour of every morning goes into turning email into spreadsheet rows.
An assistant was set up once and nobody is certain what it can still reach.
Quoting runs through one person, and it stops when they are away.
A worked example rather than a recording, at the level of detail we would show you in week three. The fourth step is the one worth reading: the assistant gets it wrong, notices, and hands back. That behaviour is designed in, and it is most of what separates a system you can leave running from one you cannot.
Message arrives at the shared inbox with a PDF attached. Sender is not in the supplier table.
Extract the invoice fields, match the supplier, check the purchase order, then queue for payment. Stop before payment, because that tool is not in scope.
extract_document returns a total of 4180.00 and a currency field that is empty.
The first pass assumed the local currency. A guard rejected it, because currency was absent from the source rather than equal to the default. Assuming here would put a wrong number on an invoice, so the run stops instead of guessing.
Routed to the named owner for accounts payable with the extracted fields, the source PDF, and the one question that needs a human answer.
Written to the audit record: what it read, what it decided, which guard fired, and who it handed to.
Scope moves the final number a long way. These are floors, published so you can tell before a call whether we are the right size for the problem.
from $2,400
Built once and handed over with documentation a person on your team can read and change.
from $6,000
It runs unsupervised because the limits were decided in advance and written down, not because we assume it behaves.
from $4,500
Answers arrive with the source attached, so a person can check the claim instead of trusting it.
from $1,600 / month
A vendor changes a format, your process shifts, and a system that was right in March is wrong by August with nobody noticing until a customer does.
The model is the cheap, interchangeable part. Nearly all of the work is the boundary around it: what it can reach, what it remembers, what it may do without asking, and what it costs to run.
If the current process lives only in one head, we write it down first. Automating an undocumented process makes the confusion faster.
Every system we ship has an off switch, a named owner, and a fallback the business can survive on. Software you cannot stop is not an asset.
You get the running cost before you commit, measured against your own volumes. Ongoing spend that surfaces after signing is a sales tactic.
Systems run in your accounts under your keys wherever the vendor allows it. We do not train anything on your data, and we do not retain copies after handover beyond what you ask us to keep for support. Where a third-party model provider sits in the path, you are told which one and what reaches it before anything is connected.
It fails to a documented fallback, usually the manual process it replaced, and it alerts a named person rather than a dashboard. On a retainer that person can be us. Without one it is somebody on your side, and part of handover is making sure they know what to do.
This is the right question to ask any contractor, and the reason handover is a named week rather than a final email. You get the system, the documentation, the reach list, the measured running cost, and the off switch. The test we hold ourselves to is that a competent person on your team could pick it up from the written record alone.
No, and we will push back if you suggest it. The work sits on top of what you already run. A migration and an automation project at the same time is two risks multiplied rather than added.
Week three runs the automation in parallel with the manual process and compares the two on your own inputs. If the comparison says it is wrong often enough to matter, you hear that from us, and the decision to continue is made on evidence rather than on how much has been spent so far.