01
Working software, in production
On your infrastructure, used by the person we built it with. Not a prototype, not a demo.
An illustrated paper diorama: a process map opens into an office, an engineer sits with an operator, the manual gap between two systems is found and bridged, and the finished automation keeps running after the room empties.
One engineer · ten days · in production
We put an engineer next to your team for ten days.
Not a pilot. Not a proof of concept. One engineer in your tools, shipping.
01 · Days one to three
It is very hard to describe your own work.
So we watch instead.
02 · What we find
By day three we can see where the hours go.
Small tasks, done by hand, over and over.
03 · The build
Then we build the thing that does them instead.
In production, doing the work. Not a demo.
04 · After day ten
Shipped. Still running after everyone goes home.
Then we start on the next thing on their desk.
Scroll ↓
DAYS 01-10
First thing in production
Shadow, pick, build with the operator, ship.
FROM DAY 11
There is always a next one
The rest of their week, then the desk next door.
YOURS TO KEEP
You own everything
Source, controls and handover from day ten.
01 · The distance
Everyone will build you an agent. Almost nobody can tell you which one you need.
Model access is not the constraint. Neither is engineering capacity. The constraint is distance: the people who can build software sit a long way from the people living inside the work.
Ask a team what to automate and you get the process document. Clean, sequential, four steps. The parts that actually eat the day are never in it.
It surfaces one way only: someone technical sitting beside the person doing the work, at their desk, on a normal Tuesday.
So we stopped asking. We watch, then we build. Whoever watches on Monday is shipping by Thursday.
It is not that people will not tell you. It is that describing your own work is genuinely hard.
Work we have found by watching
FINANCE
A spreadsheet rebuilt by hand every Monday, for the same meeting, from the same four exports.
OPS
Two systems bridged by copy-paste, because integrating them properly was never anyone’s project.
COMPLIANCE
An approval step that exists because of a mistake nobody still at the company remembers.
SUPPORT
A queue triaged by hand each morning, using rules that live only in one person’s head.
Nobody could have specified any of it in advance. That is why the rule-based tools never stuck.
02 · How it works
Ten days, start to shipped.
DAY 03 · PICK · what ships inside ten days, and what needs longer
DAYS 01-03
Shadow
One person, their real work, their actual systems. No workshop, no requirements session. We take the baseline while we are there.
DAY 03
Pick
We name what we can genuinely ship in the days left, and what needs longer than ten days. You get both lists, and we start on both.
DAYS 04-07
Build, together
Next to the operator, not in a room with a ticket. They see a working version by day four and tell us what is wrong with it.
DAYS 08-09
Validate
Against historical cases, the awkward ones included, and with other people who do the job slightly differently.
DAY 10
Ship
Into production with permissions, monitoring and a human override, plus the measured before-and-after. Then handover.
DAY 11 →
It keeps going
The same engineer, already inside, on the next thing. Days to find it, not a discovery phase.
03 · Deliverables
What lands in production.
02
A measured before-and-after
Against the baseline we took on days one to three. Your numbers, from your work.
03
A live map of everything else
Every other candidate we saw, ranked by value and difficulty. It grows each time we come back.
04
Documentation, controls, handover
Source, runbook, permissions and monitoring, so your team owns it without us.
04 · What it becomes
The first one ships in ten days. Then we keep going.
Something measurable lands every month, not at the end of a programme.
01
The first one
Days one to ten
A workflow off the operator’s desk, live and measured.
02
Then the next
Their week, then the desk next door
There are usually three more behind the first, and we have already seen them. We keep the earlier ones working as the process moves.
03
Measured every time
Against the baseline, every build
Hours back, errors down, on that workflow. You never have to take our word for it.
Ten days is where it starts, not where it ends.
05 · Qualify yourself
Is there something here for us?
Fifteen seconds, no AI knowledge required. Think of one task somebody does, then read down.
Worth a call if
Somebody does it most days, and it takes them more than an hour.
It spans two or more systems that do not talk to each other properly.
It needs judgement, which is why the rule-based tool you tried never stuck.
It has exceptions, and the exceptions are handled by hand.
The person doing it has private workarounds nobody ever wrote down.
Three or more ticked → book the call. You do not need to know which one to start with.
Wrong for you if
You want a strategy deck. We write software.
You want engineers by the hour.
You want everything automated at once. We go in order, shipping as we go.
We do not specialise in a department. We specialise in seeing what people actually do. It works anywhere a person moves between systems doing repetitive work that needs judgement: operations, finance, support, compliance, procurement, legal ops, revenue operations. Your team has the domain knowledge. What is missing is someone technical sitting next to them.
06 · Questions
The ones people actually ask.
We do not know which workflow to pick.
Good. That is what days one to three are for. If you already knew, you would need a contractor, not us.
Do you build agents?
Yes, when an agent is the right answer. Sometimes it is fifty lines of Python and an integration nobody got around to building. We will tell you which, and we are not paid more for the fancier answer.
Do you specialise in our industry or function?
No, deliberately. The hard part is not your domain, it is seeing what your people actually do all day. We bring the method, you bring the domain. The shape of the work rhymes across operations, finance, support, compliance, procurement and legal ops.
What if the biggest problem cannot be automated in ten days?
We take it on, it just runs longer than ten days. On day three you get the plan for it and what it will need. We also ship something smaller inside the ten days, so hours start coming back while the big one is still being built.
Who owns what you build?
You do. Source, docs and infrastructure in your accounts from the day it ships. No platform of ours in the middle.
What happens after day ten?
We keep going. Usually the rest of that operator’s week, then another desk. The engineer is already inside, so the next thing takes days to find. It is not staff augmentation: nobody hands us a ticket, because finding the work is our job.