MuleSoft Integration
Anypoint Platform built to the API-led pattern — system, process and experience layers, so the next integration reuses what this one paid for instead of starting again.
01
The problem
Why people call us about this.
A
Every new integration gets built from scratch because nothing before it was reusable.
B
You pay for MuleSoft licences and use them as an expensive point-to-point pipe.
C
Nobody can say which system calls which API, or what breaks when one changes.
02
What’s covered
The Salesforce we actually configure.
MuleSoft only pays for itself when integrations stop being point-to-point. We build reuse, policy and monitoring in from the first API rather than retrofitting them.
03
How it runs
Five phases, and what you see at the end of each.
01 · Week 1
Inventory
What exists, who owns it, and which system is really the source of truth. Almost always surfaces something nobody knew was live.
A written map
02 · Weeks 2–3
Contract
The design in writing, with each decision and its reversal cost named. This is where we argue with the brief — before money is spent.
A signed scope
03 · Middle
Build
Built against the contract and reviewed against it. You see working software every two weeks, in your own sandbox.
Fortnightly demos
04 · Late
Prove
Volume testing at twice expected load, deliberate failure injection, and a replay run with your team watching.
A test evidence pack
05 · Final week
Hand over
Runbook, monitoring, escalation path and a named owner on your side — then a month watching it together before we step back.
Runbook and owner
04
First call
Thirty minutes. Three answers.
You speak to a certified architect, not a sales engineer. No deck, no discovery fee, and no obligation to go further — you leave the call with three things whether you hire us or not.
Whether this is even the right line
About a third of the time it is not, and we say so. Usually the ask is custom development when the real problem sits in the data model underneath.
A shape and a range
Roughly how long, roughly how many people, and the band it falls in. The firm number follows discovery about two weeks later, and it holds.
The two risks we would flag
The things most likely to blow the timeline on a project like yours — named on the call, before anyone has signed anything.
Book it for this week.
Pick a slot directly in the calendar — most questions get answered inside the thirty minutes.
05
FAQ
Asked on nearly every call.
We own MuleSoft but barely use it. Is that fixable?
Yes, and it is the commonest place we start. We inventory what exists, then rebuild toward reusable system APIs so the next project starts from something instead of from zero.
Is MuleSoft overkill for us?
Frequently. Below roughly six interfaces, native Salesforce APIs are usually the better answer — and we would rather tell you that before a renewal than after it.
Who maintains the APIs afterwards?
Your team. Specifications in RAML or OpenAPI, policies in API Manager, dashboards in Visualizer. We hand over a runtime you operate, not a dependency on us.
Can you migrate from Mule 3 to Mule 4?
Yes. Expect DataWeave rewrites to be the bulk of the effort, which is why we scope it flow by flow rather than quoting one number for the whole estate.
Other lines