Skip to main content
All services

Automation

Nobody should bethe integration.

Workflow automation, third-party integrations, and internal tooling that removes repetitive work instead of relocating it.

  • Workflows
  • Integrations
  • APIs
  • Webhooks
  • ● TRIGGER · RULES · ACTION
  • ● SIX TIERS
  • ● EVERY RUN HAS AN EXIT

Automation.

  1. 01TriggerSomething happens
  2. 02DecideA rule, not a habit
  3. 03ActSomething changes
  4. 04ReachA system you do not own
  5. 05RecoverWhen it will not proceed
  6. 06ProveWhat the run actually did

When two systems do not talk to each other, somebody becomes the connection between them. They open one tab, read a value, open another tab, type it in, and do that forty times a day. That person is now the integration layer: undocumented, unmonitored, impossible to scale, and unavailable on the day they are ill. The work is not admin. It is a system with a human inside it.

Replacing that is mostly unglamorous engineering — reading an API that was not designed to be read, agreeing what the rules actually are when nobody has written them down, and deciding what happens to the twelve percent of cases that do not fit. The interesting part is never the happy path. Anyone can move a record from one system to another when everything is available and every field is present.

So the test we hold this work to is what a run does when it cannot proceed. Every run has to end somewhere, and there are only three honest endings: it finished, it will try again, or it has found a person and told them exactly what it needs. An automation without that third ending has not removed the manual work. It has hidden it until the day it surfaces as a silent gap in your data.

Capability overview

What we actually automate.

Engagements are usually a subset of this list, scoped to the work that is genuinely repetitive. This is engineering on your process — not a platform we have decided you should adopt, and not a rebuild of a system that is working.

06 capabilities · 30 focus areas

01Workflow Automation
The sequence itself: what starts it, what it checks, where it branches, and what it does at each step. Built so that running it twice on the same input produces the same result once, because at some point it will run twice.
  • Triggers
  • Conditions
  • Branching
  • Scheduling
  • Idempotency
02System Integration
Making two systems that were not designed for each other exchange data reliably. Most of the difficulty is not the transfer — it is authentication that expires, limits that are undocumented, and a contract that changes without notice.
  • API clients
  • Webhooks
  • Authentication
  • Rate limits
  • Contract changes
03Internal Tooling
The screens the team actually works in: a queue of things needing a decision, a form that validates before it submits, and bulk actions that do not require twenty clicks. Usually the highest-value part of the engagement and almost always the part nobody asked for.
  • Queues and forms
  • Role-based access
  • Bulk actions
  • Search and filters
  • Audit views
04Data Movement
Getting records out of one shape and into another without silently losing or duplicating them. Reconciliation is the part that matters: knowing that what arrived matches what was sent, and being told when it does not.
  • Extraction
  • Validation
  • Transformation
  • Deduplication
  • Reconciliation
05Exception Handling
What happens to the cases that do not fit. Retries where retrying helps, a place for what cannot be processed, and an escalation that reaches somebody with enough context to act rather than a notification that says an error occurred.
  • Retry policy
  • Dead letters
  • Escalation routing
  • Manual override
  • Compensation
06Run Observability
Being able to answer what ran, what it decided, and what it changed — for a specific case, weeks afterwards. Includes the ability to replay a run, which is the difference between diagnosing a problem and guessing at it.
  • Run history
  • Structured logs
  • Alerting
  • Metrics
  • Replay

Where the tool you already pay for would do the job, we will say so — a great deal of this work is configuration rather than software, and configuration that your own team can change afterwards is worth more than a bespoke system only we understand.

Automation architecture

Every run has to end somewhere.

Six tiers, and one question asked of each of them: does this run without a person, or does it exist because eventually it cannot? Four of these tiers never need anyone. The last two are the entire reason the first four can be trusted, and they are the ones that get cut from a prototype.

04 Unattended · 02 Supervised

06 Tiers · 30 Controls

  1. 01

    Trigger

    What starts a run, and what stops it starting twice

    UnattendedIntegrations07

    An event, a schedule, an inbound webhook, a watched folder, or a person pressing a button on purpose. The engineering here is less about starting than about not starting twice: the same event delivered again must not produce a second invoice, and a schedule that fires while the previous run is still going has to decide whether to queue, skip or overlap. Getting that wrong is the most common way an automation causes damage rather than saving effort.

    • Event subscriptions
    • Schedules
    • Inbound webhooks
    • Manual invocation
    • Deduplication
  2. 02

    Rules

    The decision the run is allowed to make on its own

    Unattended

    The conditions, branches and thresholds that decide what happens to this particular case. Most of the work is archaeology rather than programming: the rules exist, but they live in somebody's judgement and have never been written down, and the first honest version of them is always shorter and more wrong than everybody expects. Writing them down is the deliverable, whether or not the automation is ever built.

    • Conditions
    • Branching
    • Validation
    • Thresholds
    • Approval gates
  3. 03

    Actions

    What the run actually changes

    UnattendedBackend05

    Creating and updating records, moving files, generating documents, sending notifications, transforming data between two shapes that were never designed to meet. The important property is that an action can be repeated safely, because it will be: retries, duplicate events and reruns after a partial failure are normal operation rather than edge cases, and an action that is not idempotent turns each of those into a second real-world consequence.

    • Record writes
    • Document generation
    • Notifications
    • Data transformation
    • Idempotency keys
  4. 04

    Integrations

    The systems it reaches, and none of them are yours

    UnattendedIntegrations07

    Authentication that expires, rate limits that are not documented, pagination that changes shape, fields that are optional until they are not, and a vendor who ships a breaking change without telling anybody. This tier fails more than the rest of the system combined, and it fails for reasons entirely outside your control — which is why the tiers after it exist rather than being optional polish.

    • API clients
    • Outbound webhooks
    • Credential rotation
    • Rate limiting and backoff
    • Contract change detection
  5. A person is required below this line
    05

    Exceptions

    Where a run goes when it cannot finish

    Supervised

    A retry policy that distinguishes a timeout from a rejection, a dead-letter queue that holds what could not be processed instead of discarding it, an escalation that reaches a named person with the case and the reason attached, a manual override that is a supported action rather than someone editing the database, and compensation for the half of a sequence that already completed. This is the tier that decides whether the work was removed or hidden.

    • Retry policy
    • Dead letters
    • Escalation routing
    • Manual override
    • Compensating actions
  6. 06

    Audit

    What the run can prove afterwards

    SupervisedDatabase04

    Every run recorded with its input, its decision, its output and its outcome, kept long enough to answer a question asked weeks later. Automation moves work out of sight, and the moment it does, somebody eventually needs to know why a particular case was handled the way it was. Without a durable record the honest answer is that nobody knows, which is an unacceptable position for anything touching money, contracts or people.

    • Run history
    • Input and output capture
    • Decision trail
    • Alerting
    • Replay

Automation lifecycle

How the work is sequenced.

The order is shaped by one rule: understand the work before changing it, and be willing to conclude that some of it should not exist. Two of these stages happen before anything is built, and they are the two that decide whether the rest is worth doing.

  1. 01

    Observe

    Watch the work as it is actually done.

    Not as the process document describes it — as it happens, including the steps people added themselves to make it survivable. How often it runs, how long it takes, who does it, what they check, and which cases they handle differently without being able to say why. The undocumented exceptions are the whole engagement, and they only appear by watching.

  2. 02

    Question

    Decide what should not be automated.

    Some of this work should be deleted, renegotiated with whoever asked for it, or fixed upstream so it stops being generated. Automating a step that should not exist makes it permanent and much harder to remove, because now it has a system defending it. This stage is where we are most useful and where we most often argue ourselves out of scope.

  3. 03

    Model

    Write down the rules, and the exceptions.

    The conditions, the branches, and — more importantly — every case that does not fit them. What proportion of cases are exceptions, who currently resolves them, and what they need in order to decide. A rule set that only covers the clean cases produces an automation that hands you the mess with no context attached.

  4. 04

    Build

    Build the failure path with the happy path.

    Both at once, because the exception handling is not a later phase. Retries, dead letters, escalation and the manual override are built alongside the sequence itself, and the run history is there from the first run rather than added after the first incident that needed it.

  5. 05

    Hand over

    Leave it operable by the people who own it.

    The rules documented where the team can find them, the controls for pausing and rerunning in their hands, alerts routed to someone who can act, and the parts that are configuration left as configuration. An automation only we can change has replaced a person-shaped dependency with a supplier-shaped one.

Built to run unattended

What makes it trustworthy.

An automation is judged on the day it misbehaves, not the day it ships. These are the properties that decide whether it stays trusted, and they are the ones we would ask about before taking over somebody else's workflow.

01Every run is safe to repeat
The same input produces the same outcome once, no matter how many times it arrives. Without this, a retry is not a recovery mechanism — it is a way of doing the damage twice, and the ability to retry is what makes everything else survivable.
02Every failure has a named owner
Not a channel and not a shared inbox. A specific person or role who receives the case, the reason and enough context to act. An escalation that reaches nobody in particular reaches nobody at all, and the run is then a silent gap in your data.
03A manual override that is a real feature
Pausing a workflow, forcing a run, skipping a case or correcting a value are supported actions with a record attached — not an engineer editing the database. The moment the override is unofficial, the audit trail stops being true.
04Retries that do not amplify the failure
Retrying a timeout is sensible; retrying a rejection is not. Backoff, a ceiling on attempts, and a distinction between what is worth trying again and what needs a person — otherwise an outage upstream becomes a self-inflicted flood of requests.
05A record that outlives the run
What ran, what it decided, what it changed, kept long enough to answer a question asked next quarter. Automation removes work from view, and the record is the only thing that keeps it accountable once nobody is watching it happen.
06Credentials that belong to the system
Service accounts with their own scoped access, rotatable independently, rather than an automation running as a member of staff. An integration authenticated as a person breaks when that person leaves and grants everything they can reach.

What we build

Shapes of work this suits.

These are situations rather than case studies — the points at which manual process stops being a cost and becomes a risk. Our published project work lives under Selected Work; nothing below is presented as a delivered engagement.

01A person acting as the connection between two systems
Somebody re-typing the same values from one tool into another, on a schedule, because the two were bought years apart. The work is an integration that already exists — it is just being executed by a human with no logging and no retry.
02A spreadsheet that has become infrastructure
It started as a working file and now something important depends on it. One person maintains it, its rules live in formulas nobody wants to touch, and there is no history of who changed what. The task is usually to give it a schema and an audit trail before giving it automation.
03A process only one person understands
It works because of judgement built up over years and never written down. The first deliverable is the rules, made explicit and agreed. Whether that becomes software afterwards is a separate decision, and sometimes the documentation alone resolves it.
04Manual work that arrives in unmanageable bursts
Fine on an ordinary Tuesday and impossible at month end, during a campaign, or after an outage. The problem is not total volume — it is that the peak needs a queue, a throughput that does not depend on who is available, and a way to see what is still outstanding.
05An integration that keeps breaking quietly
Something already connects two systems, and it fails without telling anyone — a vendor changed a field, a token expired, a limit was hit. The work is usually not rebuilding the transfer but adding the exception handling and the record it never had.
06A back office that outgrew its tools
Onboarding, reconciliation, fulfilment or support running through shared inboxes and manual checklists. The result is internal tooling with queues, roles and bulk actions, plus automation of the steps that genuinely have no decision in them.

Systems layer

What it is built on.

Read from the same engineering stack the rest of the site publishes. AI is deliberately not on this list: most of this work is rules, and labelling deterministic logic as intelligence would oversell the automation and understate the engineering.

01Integrations07The systems a run reaches, each one a contract you do not control
  • Stripe
  • Paystack
  • Flutterwave
  • Third-party APIs
  • Webhooks
  • OAuth
  • Message Queues
02Backend05Where the rules actually execute, and what the run is written in
  • Node.js
  • Python
  • REST APIs
  • GraphQL
  • WebSockets
03Database04Run history, queues and the record of what was already done
  • PostgreSQL
  • Redis
  • Supabase
  • Vector Databases
04Frontend05The queues, forms and review screens a person is handed
  • React
  • Next.js
  • TypeScript
  • Tailwind CSS
  • React Native
05Infrastructure04Scheduling, delivery and the signals a run emits
  • Docker
  • CI/CD
  • Observability
  • Infrastructure as Code

What are you stilldoing by hand?

The most useful first conversation is about the work itself: who does it, how often, and what happens when they are away. Automation is usually the second answer — the first is whether the step needs to exist at all.

Start a ProjectAll services