Write-ups from deployments we have actually run, organised by section. Specific problems, the reasoning behind the approach, and what it cost to get wrong. Client names are withheld under confidentiality.
Page 8 of 8
An API integration is not a feature you ship once. It is a permanent dependency on another company's product decisions, and most of what will break it is officially classified as a non-breaking change.
Most CRM integrations fail on three decisions taken before any code is written: which system owns each field, which direction data flows, and what happens when the same event arrives twice.
Spreadsheet failure is rarely dramatic, which is why it runs for years before anyone acts. Ten observable signs, what each one actually indicates, and which of them a CRM genuinely solves.
Most requests for a custom CRM arrive as a solution rather than a problem. This is the progression we work through before writing any code, and the criteria that tell you when building is genuinely the right call.
A 100+ agent floor had call detail records split across two databases and reports assembled by hand. Here is how the reporting was automated with n8n, including the timezone correction that makes the numbers trustworthy.
A hosted PBX operator ran several client companies from one FreePBX install with no tenant separation, which made client self-service impossible. Here is the portal architecture that fixed it, including how extension sync and a browser dialler fit together.
An agent portal on shared hosting needed call data from a MySQL instance on a PBX VPS. Opening that database to shared hosting was not acceptable. Here is the API proxy pattern used instead, and why it is stronger than a firewall rule.
We typically respond within 4–8 business hours.
