Right now, someone on your team is moving data between two systems by hand.
Probably pasting an enquiry into the CRM, or checking whether an invoice was paid before anyone chases it. None of it is difficult. It just never stops, and there is more of it every month you grow.
We build the plumbing that takes those steps out, and then we look after it. Software nobody maintains tends to stop working within a year or so, which is why we stay on.
Book a working sessionWhere the time goes.
These come up in almost every company we talk to. The details vary. The shape rarely does.
| Handoff | Usually owned by | What it looks like |
|---|---|---|
| Form → CRM | Ops · daily | Enquiries get retyped into HubSpot. A week later somebody merges the duplicates. |
| Won deal → Billing | Finance · weekly | Closed deals are re-entered into Xero. By month end the two systems disagree and someone has to work out which is right. |
| Invoice → Payment | Finance · weekly | Somebody opens the ageing report and decides who to email. It is an awkward job, so it slides down the list. |
| Ticket → Engineering | Support lead · daily | Zendesk threads get summarised into Linear by hand. Most of the useful detail does not survive the trip. |
| New customer → Live | CS · per account | A checklist run across five tools. Whatever gets missed comes back as a support ticket about three weeks later. |
| Systems → Board pack | Ops · monthly | The same spreadsheet, rebuilt from the same three exports, every month. |
What we build.
Four things. We would rather be genuinely good at these than passable at everything.
Getting your systems to talk to each other.
Your tools all have APIs. Connecting them is the easy part. The work is in what happens when a request fails at 3am, or a record turns up without a field everyone assumed was mandatory.
The admin screen your ops team keeps asking for.
One page that does the job currently spread across a shared spreadsheet and four browser tabs. Built for the handful of people who will use it every day.
The Friday job that runs without anyone.
Reconciliation, chasing, provisioning, the monthly report. Work that happens on a schedule and only gets noticed when it does not.
Good at reading things. Bad at arithmetic.
We use models to read messy text, which is what they are reliably good at: enquiries, tickets, supplier documents. We do not use them to work out a number that ends up in a report.
How an engagement runs.
Four stages. You can stop after any of them, and some clients do.
A working session
Half a day with the people who actually do the work, not just whoever owns the budget. We come out of it with a map of your handoffs and a view on which three are costing you most. It is fixed price, and the map is yours regardless of what you decide next.
A written proposal
What we would build, what it will do, what it costs, and roughly how long. We also write down what we are assuming, because that is usually where estimates go wrong. Nothing starts until you have agreed to it.
Build in two-week increments
Each piece is working before the next one starts. You will not get six weeks of silence followed by a demo.
We stay on
A monthly arrangement with the same people who built the thing. Your systems will change, so what we built has to change with them. You will not be handed over to a support queue.
Probably worth a conversation if
- You are somewhere between twenty and two hundred people, and hiring into ops just to keep up.
- Each of your systems is fine on its own. The trouble is what happens between them.
- Someone can name the process that hurts and give us half a day.
Probably not us if
- You want engineers to sit inside your team. We take work off you rather than filling a seat.
- You want someone to run the process for you. We build the thing; your team operates it.
- You need IT support, laptops, or someone to look after servers.
Questions we get asked.
No. If anything we will argue against it. Ripping out software that works is an expensive way to fix a problem that lives in the gaps between systems, and it usually takes a year longer than anyone expects. We build in between what you already have.
Those tools are good and we use them when they suit the job. Where they struggle is volume and edge cases: a rate limit, a badly formed record, a run that fails halfway. Usually you get no error at all, just a row that never arrived, and you find out weeks later. The difference is the unglamorous part, which is retries, alerting, and making every job safe to run twice.
The working session is a fixed price and you keep the map whatever you decide afterwards. Anything we build after that is quoted once we have seen your systems, because a number given before then would be a guess. You get it in writing before work starts.
You do. It sits in your repositories and runs in your cloud accounts. If you stop working with us nothing switches off, and you are not waiting on us to hand anything over.
Klaipėda, in Lithuania, so inside the EU. It matters in two fairly practical ways: your data stays under GDPR without needing a transfer mechanism, and our working day overlaps the UK, the Nordics and central Europe almost entirely. We work remotely, and travel for the first session when it is worth it.
You get the map at the end of the working session. The first automation is usually live inside the first two-week increment, mostly because we start with the smallest useful thing rather than the most impressive one.
Roughly twenty to two hundred people. Below that there is often not enough repeated process to be worth automating. Above that you are generally better off hiring a platform team, and we will say so.
Start with the working session.
Half a day, fixed price. You come out of it with a map of your handoffs and a view on which ones are costing you most. Hire us afterwards or do not; the map is yours either way.