What it solves
When two systems need to agree on the same records, a no-code scenario is sometimes not enough. We build small, well-monitored integration services: authentication, field mapping, queuing, retries and alerts — so data moves reliably and someone is told when it does not.
Typical problems
- Exports and imports run by hand every week
- Records that drift apart between systems
- An integration that fails silently for days
- Rate limits and API changes breaking things without warning
- A vendor ‘native integration’ that syncs half the fields
Example workflows
Three workflows we build regularly in this service. Names and numbers are illustrative of typical outcomes; measured results are published only in case studies.
CRM to accounting sync
Won deals are re-keyed as customers and invoices in the accounting system.
A webhook on ‘deal won’ creates the customer and draft invoice, maps the line items and writes the invoice number back to the CRM.
Typical result: no double entry; both systems agree.
E-commerce to warehouse
Orders are exported nightly as CSV and imported by hand.
Orders stream to the warehouse API as they are paid; stock levels and tracking numbers flow back; failures retry and alert.
Typical result: same-day dispatch, live stock on the site.
Legacy system with no integrations
A database that nothing else can read.
A small middleware service exposes a clean API and keeps a queue so downstream tools never overwhelm it.
Typical result: an old system that finally talks to new ones.
Capabilities
- REST, GraphQL and webhook integrations
- Two-way sync with conflict rules
- Custom middleware and serverless functions (Node, PHP, Python)
- Queues, retries and idempotency
- Logging, dashboards and alerting
- Authentication: OAuth 2, API keys, signed webhooks
What every build includes
The difference between an automation that works in a demo and one that still works in a year.
- Automatic retries when a connected app is briefly unavailable, so nothing is silently lost
- A run log for every execution — what came in, what was decided, what went out
- Failure alerts to Slack or email after repeated errors, with a pause switch you control
- Idempotent steps: running twice never creates duplicates
- Written handover: a one-page map of the workflow, its owners and how to change it
- Built in your own accounts — you keep every credential, licence and asset
How the work is delivered
Map
Current process documented with the people who run it.
Scope
Written proposal, diagram, deliverables, fixed price.
Build
Short stages in your accounts, demo at the end of each.
Launch
Monitoring, alerts and documentation before go-live.
Pricing and engagement
We map the two systems, the records that must agree and the failure modes, and recommend no-code, low-code or a small custom service.
Scoped in writing after the audit. One price, one outcome, no hourly surprises. Half on start, half on launch.
Monitoring, fixes when an app changes its API, and a monthly improvement sprint. Cancel any month.
Deliverables
- Source code in your repository
- Field mapping document
- Runbook: what to do when an alert fires
- Monitoring dashboard
Questions
Custom code or Make/n8n?
If the volume is modest and the logic simple, a no-code scenario is cheaper to maintain. If you need queues, high volume, strict error handling or a vendor with no connector, a small custom service is the right tool. The audit tells you which.
Where does the code run?
In your cloud account (AWS, Azure, Google Cloud, Cloudflare) or on a small VPS you control. Nothing runs on our infrastructure.
What if an API changes?
Alerts fire, the queue holds the data, and the fix is covered by the retainer — or quoted quickly without one.
Can you document an integration someone else built?
Yes. Reverse-engineering and documenting existing integrations is a common starting point.
How does pricing work?
Every engagement starts with a free audit. You then get a fixed-scope proposal with one price and a delivery date. Ongoing monitoring and improvements are a monthly retainer you can cancel any month.
How quickly can something be live?
A first workflow is usually live within one to three weeks of sign-off. Larger builds are staged so something useful ships early and the rest follows in sprints.
What happens when a workflow fails?
Every build ships with retries, a run log and alerts. If an app changes its API, the retainer covers the fix; without a retainer we quote a small fix and turn it around quickly.
Who owns the automations afterwards?
You do. Everything is built in your accounts and documented, and your team is walked through it at handover. You can maintain it yourself or keep us on retainer.