Anatomy of a Build
The process three platforms couldn't handle.
One real engagement, taken apart in public. What the client asked for, what the diagnosis actually found, where every off-the-shelf tool hit its ceiling — and what got built past it. Delivered by JamboFlow's founder before this work carried the firm's name.
01
The presenting problem
The client came to us with what sounded like a connection problem: four separate systems — their CRM, their scheduling platform, their invoicing tool, and their operations database — needed to pass work between them in a specific sequence. Data entered once should flow all the way through. Instead, a team member was re-keying the same information into each system by hand, several times a day.
Two previous solutions had already been tried and abandoned. Both were built on integration platforms. Both worked in the demo. Neither survived contact with the real process.
02
What the diagnosis found
The presenting problem was "connect four systems." The real problem was different — and it's why the previous attempts failed. The sequence wasn't linear. Depending on the state of the record, the flow branched, waited, or reversed. A booking could change after the invoice existed. A record could enter the sequence mid-way. The previous solutions assumed a straight line; the actual process is a decision tree.
This is the pattern we see constantly: the integration isn't hard because the systems are hard to connect. It's hard because the business logic between the systems was never written down anywhere — it lived in the head of the person doing the re-keying. The diagnosis stage extracted that logic and made it explicit before a single connection was built.
"The presenting problem is rarely the real one. Here, 'connect our tools' was actually 'our process has rules nobody has ever written down.'"
03
The blueprint
Once the logic was explicit, the architecture became obvious: don't chain the four systems to each other. Chain nothing. Put the logic in one place — a central orchestration layer that owns the rules — and let each system talk only to it. Every branch, wait, and reversal lives in the layer, not in the connections.
Architecture — as presented to the client
The client saw this diagram — and understood the logic — before anything was built. That's the standard: nothing gets built until both sides are confident it solves the right problem.
04
Where the tools hit their ceiling
We always start with the best tools available — building custom where a tool would do is its own kind of failure. Here's exactly where each off-the-shelf approach stopped short, and why:
-
Integration platform, attempt one
→Could pass data forward, but had no concept of a record moving backward through the sequence. A changed booking after invoicing silently created duplicates.
-
Integration platform, attempt two
→Handled more branches, but every branch was a separate workflow. The rules ended up scattered across dozens of them — impossible to reason about, impossible to change safely.
-
Native integrations
→Each pair of systems had a native connector for the simple case. None supported the client's sequence, and chaining them multiplied the failure points.
The ceiling wasn't any single tool's fault. The process itself was the thing no platform had a shape for.
05
What was built past it
The orchestration layer was built from the ground up: custom logic that connects to each of the four systems through their APIs and owns the entire decision tree. Because every rule lives in one place, the system can do what no chained integration could — hold state, branch on it, wait on it, and reverse cleanly when the real world changes its mind.
And because we don't hand over black boxes: the client received documentation of every rule the system enforces — the same rules that used to live in one employee's head, now written down, versioned, and changeable on request.
06
The result
It has run continuously, without human input, since the day it launched. The client has not touched it — not because they can't, but because they haven't needed to.
Zero.
Manual re-keying since launch. The job the system replaced no longer exists.
One place.
Where every process rule lives. Changing the process is now a request, not a rebuild.
100%
Uptime on the process since go-live. Continuous operation, no intervention.
Your operation has a version
of this problem too.
Thirty minutes. We'll map your operation and identify where the right system would make the most impact — no pitch, no pressure, no obligation.
Start a conversation →