Client
CNC Cabinetry
Case study
The project began where the off-the-shelf connector stopped: the business needed a fuller, more intentional contract between NetSuite and HubSpot.
Client
CNC Cabinetry
Role
Integration architecture and development
Year
2026
Summary
Built a custom NetSuite-to-HubSpot integration when the available marketplace connector could not provide the complete business data CNC Cabinetry needed.
CNC Cabinetry had already identified the natural integration path between NetSuite and HubSpot, but the marketplace application did not surface all of the data the team relied on.
I built a custom integration so the business could define the data contract around its actual process rather than the limitations of a generic connector.
Packaged integrations are valuable when their assumptions match the organization. They become limiting when important records, fields, relationships, or update rules fall outside the supported model.
Adding more automation around an incomplete sync would not solve that problem. The project required a clearer understanding of what HubSpot needed, where NetSuite remained authoritative, and how those values should move over time.
The custom middleware established an explicit boundary between the platforms:
The integration focused on the full data set the operating team depended on instead of reproducing the smallest common denominator between the APIs.
Custom does not automatically mean better. In this case, it was justified because the gap affected essential business context and could not be configured away.
By keeping the integration narrowly focused on the missing contract, the solution avoided turning into a replacement ERP or CRM. NetSuite and HubSpot retained their roles, while the middleware coordinated the information needed between them.
This project demonstrates how I evaluate build-versus-buy decisions for integrations. I prefer the simplest connector that satisfies the workflow, but I am comfortable building the missing layer when the packaged option cannot represent the business accurately.
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.