Remote · in the systems you already runScoped in writing before anything is built
The practice · Remote · in the systems you already run
How the work actually runs.
Nearly every business runs on a handful of good tools that do not know about each other, with a person in the middle acting as the integration. That person is the most expensive and least reliable part of the chain, and they would rather be doing almost anything else.
Every build follows the same arc, whether it is a fortnight of work or a quarter of it. Nothing below happens out of sequence, which is the entire reason it is written down.
Step 01
The conversation
What actually happens now, in your words, including the bit everyone works around. No demo, no deck. If nothing here is worth automating, that is where it ends and it costs you nothing.
Step 02
The map
The process written down properly: every branch, every exception, every system it touches. This is usually the first time anyone has seen the whole thing in one place, and it is where most of the surprises surface.
Step 03
The plan, in writing
Exactly what gets built, what it will and will not do, and what counts as finished. Agreed before any code exists. If the shape changes later, we stop and re-agree rather than quietly absorbing it.
Step 04
Built and tested
Built, then run against your real cases, the awkward ones included, before it goes anywhere near live. Nothing goes into production on the strength of a happy path working once.
Step 05
Live, with the lights on
It goes live with monitoring on the paths that matter and a short stabilisation window behind it. Anything that surfaces in that window gets fixed fast. That is planned for, not an admission.
After
Still being watched
Your business keeps moving and so do the tools underneath it. Ongoing upkeep means problems are usually found here first. It ends whenever you want it to.
Services in detail
Everything we do, and what it involves.
Six service lines, each with what actually happens, roughly how long it takes, and how the engagement is shaped. Anything outside this list, we will point you at someone who does it properly.
01
Automation Systems
The job that comes back every week, handed to something that does it the same way every time, whether anyone remembered or not.
Most of what eats a week is not hard, it is just relentless: the same form re-typed into the same system, the same follow-up nobody got to, the same report rebuilt by hand every Monday. We map the whole path first, including the exceptions everybody works around, then build the version that runs on its own. What cannot be decided by a rule is routed to a person on purpose, not dropped.
The whole path mapped before a line is written, exceptions included
Runs on a schedule or on a trigger, so no one has to remember
Anything it cannot decide is handed to a person, never silently dropped
Every run leaves a record you can read without us
Built to be switched off as easily as it was switched on
Used for the judgement calls a rule cannot make, and kept well away from the parts that were never broken.
A lot of work is deterministic and should stay that way: rules are cheaper, faster, and they do not surprise you. AI goes in where the input is messy and the judgement is real: reading an unstructured email, sorting an exception, drafting a first pass a person then approves. It gets a narrow job, a defined fallback, and a human check on anything that matters.
Rules first, with AI only where the input genuinely varies
A defined fallback for every call it is allowed to make
Draft-and-approve by default on anything that leaves the building
Its reasoning is logged, so a wrong call can be traced
Swappable, so the system never depends on one provider
Internal tools shaped around how the work is actually done, instead of the work being reshaped around a subscription.
When the off-the-shelf option fits at eighty percent, the last twenty is usually where the real cost hides: the spreadsheet beside it, the double entry, the workaround everyone has stopped noticing. A small, purpose-built tool removes that seam. It stays small on purpose: one job, done properly, owned by you.
Built for one business, not configured down from a hundred thousand
Runs on infrastructure in your name, not rented from us
Source, documentation, and access handed over as standard
The quiet plumbing between the tools you already pay for, so the same information stops being typed in twice.
Almost every business runs on a handful of good tools that do not know about each other, with a person in the middle acting as the integration. That person is the most expensive and least reliable part of the chain. We replace that seam with something that moves the data, checks it arrived, and says something when it did not.
One record, moved once, checked on arrival
Failures are noisy on our side and quiet on yours
Historical data reconciled before anything goes live
Works with what you already own, so nothing gets ripped out
Shipping is not the end of the job. Things get watched, and problems get found here before they get found there.
Anything worth relying on is worth watching. Every build ships with monitoring on the paths that matter and a short stabilisation window afterwards, where anything that surfaces gets fixed quickly. That is expected, not a sign something went wrong. After that it is ongoing: the business changes, the tools it depends on change, and the automation has to keep up with both.
Monitoring on the paths that actually matter, not a dashboard for show
A stabilisation window after every launch, planned for from the start
Fixes in that window are part of the work, not an extra
Changes tracked, so you can see what moved and when
Ends whenever you want it to, with nothing held hostage
Not a helpdesk. The general technical problems that sit between a business and getting on with its day.
Sometimes the thing blocking a process is not the process. It is the account nobody can get into, the machine that has not been updated since it was bought, or the setup that grew by accident and now nobody understands. We will sort that out when it is in the path of work we are doing, and tell you plainly when you would be better served by a dedicated IT provider.
The technical blockers sitting in front of the actual work
Accounts, access, and the setup nobody documented
Straight answer on what is worth fixing and what is not
A referral, not a stretch, when it needs a specialist
Kept deliberately small, because this is not the main service
Automation without upkeep quietly rots. Software without the plumbing becomes another island. They are separated here to explain them, not to sell them one at a time.
AU
Automation
Typically 2–5 weeks
Recurring work · triggers, rules, exceptions
The core of it. Processes that repeat on a schedule or a trigger, mapped end to end, including the exceptions people quietly work around, then handed to something that does not forget, does not get busy, and does not go on holiday.
Process mappingTriggered workflowsException routing
SW
Software
Typically 4–10 weeks
Custom tools · integrations · data
For the gap no subscription quite covers. Small internal tools built for one business and owned by it outright, plus the plumbing that gets existing systems talking so the same information stops being typed in twice.
Internal toolsSystem integrationData migration
UP
Upkeep
Ongoing, ends when you say
Monitoring · stabilisation · the long tail
The part most quotes leave out. Monitoring on the paths that matter, a stabilisation window after every launch, and someone still paying attention when the business changes shape around a system that was built for how it used to be.
MonitoringStabilisationOngoing changes
One line of accountability
The person who scoped it is the person who builds it, and the person still watching it in six months.
No account layer, no handover to a delivery team who were not in the first conversation, and nothing lost in the gap between the two. It is the main reason the scope written at the start still describes the thing at the end.
Under the hood
Choices that remove a phone call.
Every technical decision here is made for one reason: it either stops something breaking quietly, or it saves you having to ask anybody what happened. Anything that only looks good in a proposal got left out.
Fig. 02 · One decision
Mapped end to end first
Every branch and exception written down before anything is built. It is unglamorous and it is where most of the real cost of a project is found, long before any of it is code.
Rules before models
Deterministic steps stay deterministic, because they are cheaper to run and they behave identically every time. A model is introduced only where the input genuinely varies.
Failure is loud here, quiet there
Things break. What matters is who finds out first. Monitoring sits on the paths that matter so a failure raises an alarm on this side rather than surfacing as a confused customer on yours.
Handed over, not held
Source, documentation, and infrastructure in your name from the start. The test of a good build is whether someone else could pick it up, so it is written as though they will.
Automation systemsAI where it earns its placeCustom internal softwareSystems that talk to each otherMonitored after launchScoped in writing firstNo vendor lock-inBuilt around how you already workIT, when it is in the way
Automation systemsAI where it earns its placeCustom internal softwareSystems that talk to each otherMonitored after launchScoped in writing firstNo vendor lock-inBuilt around how you already workIT, when it is in the way
Bring the one that keeps coming back.
One process, described in your own words. You will leave with it mapped end to end and a straight answer on whether handing it over is worth doing, whether or not you ever build it.
