What we build
Four kinds of work, and one way of doing them
Most engagements start in one of these and grow into another, which is why they are one page rather than four. Underneath, every one of them is assembled the same way — and that part is written out below, because it is what a technical reviewer has to approve.
01
Reading documents and records
Making information in documents searchable, structured and checkable.
The answer is somewhere in a contract, an email thread, a PDF or six years of records — and finding it takes a person half an hour every time.
We apply AI to the jobs it is genuinely good at: reading documents, extracting structured fields, classifying, summarising, and surfacing the right record from a large pile. Measured against a human baseline before anything depends on it. Not a chatbot bolted to a homepage.
- Extracting fields from invoices, contracts and forms
- Classifying and routing inbound work
- Summarising long documents and threads
- Searching your own records by meaning rather than keyword
- Decision support that shows its reasoning rather than a score
02
The work between the steps
Turning the repetitive part of a process into something that runs itself.
The work between your systems is done by people: copying fields, chasing approvals, sending the same email, updating the same spreadsheet. It is invisible in every process document and it consumes real hours.
We map the workflow as it actually runs, automate the mechanical steps, and leave the judgement with people. Approvals, notifications, handoffs and status stop depending on somebody remembering.
- Approvals with a visible rule, a status and an audit trail
- Exception queues, so only the interesting cases reach a person
- Scheduled reconciliation that runs before anyone has to do it by hand
- Document generation from the source files rather than last month's copy
- Notifications that reach a person when something actually needs one
03
Making two systems talk
Connecting what you already run, without migrating off any of it.
Two systems are each fine on their own. Together they generate a morning reconciliation job, a double-entry habit and a transcription error rate nobody measures.
We build the integration layer through documented interfaces, with credentials you own and can revoke. Designed for failure rather than for the happy path: retries, dead-letter handling, and alerts that reach a person instead of a log nobody reads.
- APIs, webhooks, scheduled pulls, file drops and email ingestion
- An agreed system of record for every field, so nothing silently disagrees
- Keeping two systems in step without either one being replaced
- Pulling exports out of software that has no API at all
04
Software built to order
The tool your process actually needs, when nothing off the shelf fits it.
A business-critical spreadsheet understood by one person. Or a package that does eighty per cent of the job and fights you on the rest.
We build the thing itself — in your repositories, in your infrastructure accounts, documented for whoever comes next. Short increments with something to look at at the end of each, rather than a quarter of silence and a reveal.
- Moving a process off a spreadsheet without moving it off what people understand
- Internal tools for work that currently happens in email
- Portals and dashboards over data you already hold
- Replacing a package that fits the process badly in one specific place
Architecture
How it fits together
Eight layers, top to bottom. Written for the person who has to approve it rather than the person buying it — those are usually two different readers, and only one of them gets a page on most vendor sites.
01
Business systems
Your CRM, ERP, HRIS, accounting package, databases and inboxes.
These stay exactly as they are. Nothing below replaces them, and nothing requires migrating off them.
02
Integration layer
APIs, webhooks, scheduled pulls, file drops and email ingestion.
Reads and writes through documented interfaces using credentials you own and can revoke. Designed for failure: retries with backoff, dead-letter handling, and alerts that reach a person rather than a log nobody reads.
03
Workflow engine
The sequence — what happens, in what order, and what waits for what.
Each run is a record: what triggered it, what it did, what it skipped and why. This is what makes the automation auditable rather than mysterious.
04
AI services
Extraction, classification, matching and summarisation.
Called for the specific steps where they beat rules, and nowhere else. Behind a provider abstraction, so the model can be changed without rewriting the workflow around it.
05
Business rules
Thresholds, routing, and what counts as an exception.
Explicit and configurable rather than buried in code. Confidence below a threshold stops and waits; so does anything matching an exception rule.
06
Human approval
The gate on anything consequential.
Which steps require a person is a decision made per workflow, reviewed as the measured error rate justifies it — not a default that quietly erodes.
07
Actions
Writing back, notifying, filing, posting.
The point where the automation changes something. Every action is logged with its inputs, so an unexpected outcome can be traced rather than guessed at.
08
Analytics
Volume, duration, error rate, exception rate.
Instrumented from the start. It is how you find out whether the thing was worth building, and the first place to look when something changes.
How we deliver
A rhythm you can plan around
The second stage is the one that de-risks the whole thing: whatever decides whether the project works gets built first, with your real data, before anyone commits to the rest.
01
Sit with the team
1–2 weeks
We watch how the work actually happens — not how the process document says it does. You get a costed plan and an architecture at the end, yours to keep either way.
02
Prove the hard part
2–3 weeks
Every project has one piece that decides whether it works. We build that first, with your real data, before anyone commits to the rest.
03
Build
Ongoing
Short increments, something you can look at at the end of each one, and a staging environment your team can try. Automated tests and code review on every change.
04
Run, or hand over
Post-launch
Monitoring, incident response and a roadmap that keeps moving — or a clean handover to your own team, documented properly. There is no version of this where what we built stops working because you stopped paying us.
The commercial side of this — what the discovery fee covers, what you keep, and what is committed when — is on how working with us runs.
The questions we actually get
What a technical reviewer asks
These five come up in almost every technical conversation, so they are answered here rather than waiting for a call.
- Where does our data go?
- Into the systems it already lives in. The integration layer moves what a workflow needs and no more, and we build inside your infrastructure and accounts wherever your environment allows it.
- What happens when the AI is wrong?
- It stops. Confidence below the threshold routes to a person instead of proceeding. The interesting design question in any of this work is not what happens when the model is right — it is what happens when it is not.
- Are we locked to one AI provider?
- No. Model calls sit behind an abstraction, so swapping providers is a configuration change rather than a rewrite. This matters more than it sounds: this part of the market is moving quickly.
- What happens if you disappear?
- You keep everything. Source code in your repositories under your licence, infrastructure in your accounts, documentation written for whoever comes next. We would rather be kept because the work is good than because leaving is painful.
- How do we know it is still working?
- Monitoring and alerting that reaches a human, plus the analytics layer. Silent failure is the failure mode that costs real money, and an automation that quietly stops is worse than one that never existed.
Security
Principles, not certifications
Security is designed around your environment, your data sensitivity and what you have to answer for — not a checklist applied to everyone.
We hold no security certifications and do not claim any. If your procurement process requires SOC 2, ISO 27001 or a signed BAA, tell us early — it changes what we can responsibly take on.
- Least-privilege access to every connected system
- Secure API authentication with credentials you own and can revoke
- Encryption in transit and at rest
- Audit logging of automated actions
- Role-based access control
- Human approval gates on consequential steps
- Separated development, staging and production environments
- Data minimisation — we move what the workflow needs, not everything
- Configurable retention, set to your policy
- Monitoring and alerting that reaches a person
Rather see it than read about it?
These ideas are running on this site, with synthetic data and the real logic underneath. Every rule is on show, so you can check the reasoning instead of taking it on trust.
Find one workflow worth automating
You do not need to replace your technology stack. Start with one process that costs your team hours every week.