Stop paying people to retype data between systems
You get your tools connected properly: payments, messaging, accounting, scheduling. Built so a vendor's change shows up as an alert instead of a missing invoice.
An integration is judged on the bad day, not the good one. On the good day everything responds and the data lands. On the bad day a payment provider is slow, a webhook arrives twice, and a field you relied on comes back empty. A well-built integration handles all three without a human noticing. A badly built one looks identical until the moment it does not, and by then a week of records is missing.
The silent failure nobody is watching
Integrations break quietly. A vendor deprecates a field, a token expires, a rate limit tightens. Nothing crashes. Records simply stop arriving on one side while everything looks normal on the other.
Then the retry problem. Networks time out, so the same request often arrives twice. Without protection, one payment becomes two charges and one order becomes two shipments. Your customer finds that before your dashboard does.
So the useful question is not whether the systems can connect. It is what happens on the day one of them misbehaves.
What is connected now
Counted, not estimated
22
systems in production, every one of them integrated
7
named services linked through Maidily, from Stripe to QuickBooks
7
integrations behind Broollie, from Zoom to Zendesk
1
government service called live: the UK Right to Work API
What we actually connect
Real integrations, running for named clients.
Money in, books updated
Maidily links Stripe, Square, Twilio, QuickBooks, Zapier and Mailchimp into one operations platform for cleaning companies. Scheduling, invoicing and messaging stop being six separate logins.
Meetings that turn into work
Little Tree Confections runs an n8n workflow that reads every Fireflies transcript, then creates department-specific ClickUp tasks and Notion docs. No handoff, no rekeying.
Checks against systems you do not control
Shift Link calls the UK government's Right to Work API during worker onboarding, then only offers shifts to people who pass. That cut manual compliance verification by 70%.
Marketplace payments held and released
WorkMateAI uses Stripe Connect to hold funds against the work and release them when it is done, with e-signature and dispute handling alongside. The money movement follows the job state.
- MapWhich system owns which record.
- ContractFields, limits, what the vendor promises.
- BuildRetries, duplicates, partial failures.
- ReconcileA daily check that both sides agree.
- WatchAlerts on silence, not only on errors.
Watch is the node that catches the real failure mode. An integration that stops sending never throws an error, so silence has to be something you alert on.
Making a repeated request harmless
Every integration eventually sends the same request twice. A timeout, a retry, a webhook delivered again by a provider doing its job properly. The receiving system has to recognise the repeat.
That is a design decision, not a bug fix. Each operation carries a key the receiving side remembers, so the second attempt returns the first result instead of doing the work again. Get this wrong in a payments flow and you refund the difference, then explain it.
- Repeated calls return the original result instead of creating a second record.
- Webhooks are verified, because a public URL accepts anything until you check.
- Failures back off and escalate rather than hammering a struggling vendor.
- A daily reconciliation compares both sides, so drift is found within a day.
What we have connected
Payments
Messaging
Work and calendars
How we build them
Integrations running now
Maidily
Integrated operations platform for residential cleaning businesses.
Read the case study →
Little Tree Confections
n8n + AI meeting-to-action automation for an artisan bakery.
Read the case study →
WorkMateAI
Dispute resolution, payments, and compliance for Australia's on-demand trades.
Read the case study →
“They were incredibly responsive.”
Mony · CEO, Maidily
The quick integration against ours
Both work on the day they ship. They diverge the first time a vendor has a bad afternoon.
| Criterion | The quick version | How we build |
|---|---|---|
| Repeated requests | Create a second record, and a support ticket. | Recognised by key, and return the first result. |
| When the vendor is down | Retries immediately, until the rate limit bites. | Backs off, queues, and escalates if it stays down. |
| Webhook security | A public URL that trusts whatever arrives. | Every payload verified before anything is written. |
| How you find out it stopped | A user asks where their data went. | An alert on silence, plus a daily reconciliation. |
| Credentials | A shared key in an environment file, forever. | Stored encrypted, scoped narrowly, rotatable without a redeploy. |
01How do we connect systems that were never meant to talk to each other?
Through whatever interface each one already exposes, in order of preference: a documented API, then webhooks, then a scheduled file exchange. The work is rarely the connection itself. It is agreeing which system owns each record, so the two never disagree about the same customer.
02Should we use Zapier or n8n instead of building something?
Use them when the workflow is simple, low volume, and you can live with it stopping for a day. We use n8n ourselves for exactly that, including the Little Tree Confections pipeline. Build custom when money moves, when volume is high, or when a silent failure would cost you more than the build.
03What happens when a vendor changes their API?
You get told before your customers do, if someone is watching. We pin the version where the vendor supports pinning, alert when responses change shape, and keep the integration under an agreed service level or a documented handover. An unwatched integration will eventually break without anyone noticing.
04Can an integration write into our production database?
It can, and it should do so through a narrow, deliberate path rather than direct table access. Direct writes from an outside tool skip your validation and your audit trail, which is fine until the day someone needs to explain a record. We put a service in front of it, with permissions scoped to the specific job.
05How do you handle API keys and credentials?
Keys live in an encrypted store, scoped to the narrowest permission that does the job, and rotatable without a redeploy. They never sit in the codebase. Trading CoPilot stores broker credentials encrypted in Supabase, with per-user row-level security so one account cannot reach another's.
06Our two systems disagree about the same customer. Can that be fixed?
Yes, by deciding which system is the source of truth for each field and making the other one follow. Most disagreements come from both sides being allowed to write the same thing. Once ownership is written down, a daily reconciliation catches drift within a day rather than at the quarter's end.
07What does an integration cost to build and run?
Cost is driven by how many systems are involved, how good their APIs are, and how bad a silent failure would be for you. A well-documented API with webhooks is straightforward work. A vendor with no API and a nightly file drop is not, and the drivers get named on the free scoping call.
08We are a small team without engineers on call. Who watches this?
Either we do, under an agreed service level, or your team does after a documented handover. Pick at the start rather than after the first outage. Enterprises usually want the alerts routed into their own monitoring, and we set that up instead of running a parallel one.
Related
- Business process automation →When the integration is the whole point.
- Idempotency key →The mechanism that makes a repeated request safe.
- n8n vs Zapier →Which tool fits a simple workflow.
- Settlement vs authorisation →Why payment records rarely match on the first pass.
- Maidily →Seven named services behind one operations platform.
