The work nobody should be doing, done by something else.
We find the two or three processes in your business that are eating a person’s week, build the systems that run them, and stay on to keep them running. Fixed scope, published prices, and documentation good enough that you could fire us.
Four ways people arrive at this page
Find the one that sounds like you.
“We know exactly what to automate”
You have a process, you can describe it, and you want it built. Skip the assessment. Send us the description and we will scope it and quote a fixed price before any work starts.
Most automation projects fail after the demo, not during it.
The build is the easy part. What breaks a project is everything after it: nobody watches the thing, an API changes and it fails silently, the person who understood it leaves, and eighteen months later there is a system in your business that everyone is afraid to touch.
So we sell the part everyone else treats as an afterthought. Every build ships with the tests, the monitoring, the runbook and the documentation that make it survivable. If that sounds unglamorous, it is, and it is the entire difference between an automation and a liability.
Built to be watchedEvery workflow reports its own health. Failures alert us before they reach you.
Built to be changedDocumented well enough that your team, or a different vendor, can pick it up without archaeology.
Built to be leftEverything runs on accounts in your name. Leaving us is an inconvenience, not a rebuild.What we build
Five shapes of work. Most engagements are one or two of them.
What ships with every build
A demo needs none of this. A system that runs your business needs all of it.
A golden test set
A fixed set of real inputs with known correct outputs, agreed with you. Every change is run against it before it ships. This is how we know a fix did not break something else.
Evals, not vibes
Where a model is making a judgment, we measure how often it is right against that test set, and we re-run it weekly after launch. Model behaviour drifts. Systems that nobody re-measures degrade quietly.
Cost caps and circuit breakers
Hard spend limits per workflow and automatic stops on runaway loops. An automation that can spend without a ceiling is a bill waiting to happen.
Defined handoff points
Every workflow has a stated threshold where it stops and a person decides. We agree those thresholds with you rather than choosing them for you, and they are written down.
A runbook your team can follow
What this does, what it touches, what breaks it, how to restart it, and who to call. Written for the person who inherits it, not for us.
Monitoring and incident response
Every workflow reports its own health. When something fails it alerts us, and under Care the first you usually hear of it is the note saying it is fixed.
Assessment to production
Every engagement runs on the same clock, and the scope is fixed in writing before the build starts.
Assess
We sit with the people doing the work and watch the actual process rather than the description of it. You get a map of where the hours go, a shortlist sized in hours and dollars, and a fixed price for whatever is worth building. If nothing is worth building, we say so and you keep the map.
You get · a map and a fixed priceBuild
Connections built, the workflow running on real data behind a flag, the golden test set agreed and passing. You review output, not a slide about output.
You get · a working system on your dataHarden
Run it against the ugly inputs. Set the thresholds where a person takes over. Cost caps, circuit breakers, alerting, and the eval baseline that everything after this is measured against.
You get · measured accuracy and a safety floorHandover
Repo, prompts, accounts, runbook, and a working session with whoever on your side will own it. Then you decide: run it yourselves, or keep us on under Care.
You get · everything, in your name[Eight] weeks is the normal shape. Simple builds finish sooner and we say so before you pay. The one thing we will not do is start building before the scope is written down, because that is how a fixed price becomes an hourly one.
What we have built
Described by what they do, since most of them are under NDA.
Work shipped for
See the work →
What happens when it breaks
It will, eventually. An API changes, a vendor deprecates something, a format shifts. What matters is whether anyone finds out before you do.
The warranty
Under Care
If you leave
Whether this fits
Pricing
Published, because a firm that will not tell you what something costs until you take a call is telling you something.
Prices in USD. Builds are quoted at a fixed price before work starts and we do not bill hourly. Scope changes are repriced and approved before work continues.
Why these numbers
Below about $3,000 this work is done by a freelancer assembling something in a no-code tool with no tests and no documentation. Above about $20,000 it is done by a firm that needs to bill for a sales team and an account layer. Both produce systems that break in the same way, for different reasons.
We sit in between deliberately. The build price is what it costs to do the engineering in the section above properly, once, at a scope small enough to finish. And Care is priced to be worth keeping rather than to be the real product.
The firm behind the work
Automation is one of three things we do. Most clients arrive through one and end up using two, and none of them require the others.
Questions
If your question is not here, one of us will answer it directly.
Still have questions? →From $6,500, quoted at a fixed price in writing before any work starts. Most single-process builds land between [$6,500 and $15,000]. If a scope is bigger than that we will usually suggest splitting it, because long builds are where fixed prices go wrong for both sides.
NextWhether there is anything here
worth building
Tell us what is taking the time. We will say whether it is worth automating, roughly what it would cost, and whether a person should just keep doing it. Some of the time that last one is the answer.