I build the systems your business runs on, then I keep them running
I am Harry Rainbird, an independent automation engineer — British, based in Lille, France. I work with operations teams whose processes span more systems than any one person can hold in their head.
Book a free call09:00:04 crm-contact-sync ok 1.2s09:00:11 invoice-reconcile ok 0.9s09:00:19 document-dispatch ok 2.4s09:00:26 onboarding-checklist ok 0.7s09:00:31 folder-provision ok 1.1s03:14:02 nightly-backup-export failed — ↳ no alert configured. silent for 11 days.
01 — what I build
The busywork between your systems, done for you
Most of what I build is unglamorous: the copying, chasing and checking your team does by hand because your tools do not talk to each other.
-
Won deals turn into signed contracts and invoices
A deal is marked won in Pipedrive or Teamleader. The contract goes out through RightSignature, and once it is signed the invoice is raised in QuickBooks or Xero and a client folder appears in ShareFile.
-
Enquiries never sit in an inbox
A website form lands in HubSpot as a contact with an owner and a follow-up task, and the right person gets a Slack or Teams message straight away.
-
Payments reconcile themselves
Every night, Stripe payments are matched against invoices in Xero or QuickBooks. You only see the handful that do not match.
-
Paperwork that chases itself
Documents are generated from your Knack or Airtable records, sent for signature, chased until they come back, and filed in SharePoint.
-
New starters are set up on day one
Add someone once and they get a Microsoft 365 account, access to the right SharePoint sites and Teams, and an onboarding checklist that reminds people what is still outstanding.
02 — the pitch
The part AI does is the part that was never hard
A model will write the integration. It will do it quickly, and the code will mostly be right. That was never where these projects failed.
They fail eight months later, quietly. A vendor renames a field. A payment provider starts returning a status nobody has handled. Someone in finance adds a column to the sheet that feeds the whole thing. The job keeps reporting success while moving nothing, and no one finds out until a student turns up without a visa letter.
What you are actually buying is not the code. It is someone who holds the credentials, knows why the enrolment flow has three exceptions that nobody wrote down, and fixes it when it breaks.
03 — failure modes
Silent failure
The run reports success and does nothing. Nobody is watching the logs, so nobody knows. The most common failure and by a distance the most expensive.
Upstream drift
An API changes a field, a status code, an auth flow. Your automation was correct the day it was written and is wrong now, through no fault of whoever built it.
Exceptions nobody documented
The handful of cases your process treats differently. They live in one person's head, never make it into the brief, and are why a technically perfect build still returns wrong answers.
It belongs to nobody
An automation is owned by whoever built it. If that was a contractor who moved on, or a chat window you closed, then when it fails it is nobody's job to fix — which means it is yours.
04 — engagement
phase one
Build
I map the process as it actually happens, exceptions included, then build it as custom code across the systems you already pay for. No new platform to buy, no migration, no per-step fees that grow with your volume, nothing for your team to learn. You get documentation your operations lead can actually read.
phase two — ongoing
Run
Monthly. Every automation is monitored, every failure raises an alert to me, and I fix it — usually before you have noticed. When a vendor changes their API, that is my problem rather than yours. You always know what is running and whether it is healthy.
05 — in production
Where this runs
Currently a study-abroad provider: a Knack database, Make, HubSpot, SharePoint and a payments platform that natively talk to none of each other. Student enrolments and programme setup, payment reconciliation, document generation and signature chasing, pre-departure compliance, certificate issuing, and staff access provisioning across dozens of programme sites.
Dozens of scenarios running unattended, every one of them monitored. The operations team does not think about any of it, which is the entire point.
- systems
- Knack · Make · HubSpot · Microsoft 365 & SharePoint · payment and e-signature platforms
- built with
- Python · REST and webhook integrations · scheduled jobs
- operations
- health checks · failure alerting · runbooks · change logs
06 — fit
worth a conversation if
- A process you depend on spans three or more systems that do not talk to each other.
- Something important happens only because a specific person remembers to do it.
- You already have automations running that nobody owns or monitors.
- You have been quoted for a platform that would replace tools you are happy with.
probably not if
- You want a one-off build at the lowest possible price. A legitimate thing to want; I am not the best value for it.
- You need someone on site, or inside your org chart.
- The process is already stable, monitored and owned in-house. Leave it alone.
07 — questions
Common questions
Which tools do you work with?
I write custom code that connects Knack, HubSpot, Microsoft 365, Pipedrive, Teamleader, Airtable, QuickBooks, Xero, Stripe, ShareFile, RightSignature, Google Workspace and Slack. If a system has an API it can usually be connected. Already running automations in Make? I can look after those too.
Why custom code rather than Make or Zapier?
Make and Zapier charge for every step an automation runs, so the bill grows with your business. Custom code costs roughly the same to run whether it handles ten records or ten thousand. It also copes with the awkward exceptions no-code tools struggle with, and every change is recorded. If your existing scenarios work, I can look after them as they are and move them over when the numbers make sense.
Do we need to switch to new software?
No. I build across the systems you already pay for. No new platform to buy, no migration, and nothing new for your team to learn.
What happens after it is built?
On the monthly plan every automation is monitored and every failure alerts me, so most problems are fixed before you notice them. When a vendor changes their API, that is my problem rather than yours.
Can't we just use AI to build it ourselves?
For the first version, often yes. What AI will not do is notice when it quietly breaks eight months later, or know about the exceptions nobody wrote down. That ongoing ownership is what you are paying for.
How do we get started?
Book a free call. Bring the process that annoys you most and I will tell you honestly whether it is worth automating, and whether I am the right person to do it.
08 — next
Book a call
No charge, no pitch. Bring the process that is annoying you most and I will tell you honestly whether it is worth automating, and whether I am the right person to do it.
I am booked out at the moment, so new slots are limited — what is showing below is genuine availability. If nothing fits, email me and I will let you know when that changes.