Client
NOLS
Case study
The challenge was not a point-to-point sync. It was coordinating three platforms with different responsibilities without allowing updates to become ambiguous or circular.
Client
NOLS
Role
Middleware architecture and integration development
Year
2025–2026
Summary
Built middleware coordinating data movement between Dynamics 365, WordPress, and HubSpot so three distinct systems could participate in one dependable workflow.
NOLS needed Dynamics 365, WordPress, and HubSpot to exchange information as part of a shared customer and marketing workflow.
I built a middleware application that coordinated those systems while keeping their individual responsibilities visible.
In a point-to-point integration, ownership can often be expressed as a relationship between two records. With three systems, the number of possible paths grows quickly.
A WordPress action may need to reach Dynamics, HubSpot, or both. A change in Dynamics may affect the context HubSpot uses. If every platform can update every other platform without a clear contract, loops, stale values, and conflicting records become difficult to avoid.
The middleware served as the coordination layer rather than embedding integration logic independently in each platform.
The implementation focused on:
WordPress remained responsible for the relevant website experience, Dynamics retained its application and business role, and HubSpot received the context required for its CRM and marketing workflows.
Centralizing the integration contract made the system easier to reason about. Platform-specific API behavior could be handled at the edge, while the core workflow used a consistent internal representation.
It also reduced coupling. A change to one API or field mapping did not need to be reproduced across two separate direct integrations.
This project demonstrates how I approach multi-system architecture: make ownership explicit, coordinate through a focused boundary, and design retries and failures as normal operating states. That discipline keeps a three-platform workflow from becoming three competing sources of truth.
Related writing
Boring integrations stay reliable because their contracts, ownership, and failure handling are explicit from the start.
Integrations stay safer and cheaper to evolve when teams define field meaning, ownership, and failure behavior before the first sync goes live.
Systems stay easier to operate when teams decide source of truth by workflow state and correction path instead of letting multiple tools feel authoritative at once.
Relevant services
Custom app builds and integration work for teams that need systems to talk cleanly across HubSpot, internal tooling, and the rest of the stack.
Complex HubSpot implementations for teams that need more than standard workflows and out-of-the-box automation.