Native app, HubSpot Data Sync, Skyvia, or custom: how to choose a HubSpot integration approach

Each question is cheaper to answer than the one after it. Asking them out of order is how a team ends up scoping middleware for a problem the marketplace had already solved.

Effort is hours of our time to build, never a price. Custom carries three bands because it covers three genuinely different shapes of work: a light one way feed of three objects or fewer, a standard two way sync with custom objects and watermarks, and an enterprise build spanning several systems. Loading the history is a separate job from keeping two systems in step, and it comes first. See migration or integration.

A manufacturer running a point of sale system on a SQL Server inside their own network asked for an integration, and everything about the request pointed at custom. The database is unreachable from the internet. There is no marketplace listing. The schema runs to more than 724 base tables, over twenty of them involved in a single transaction. Their reseller offered to build a REST API, scoped at roughly four weeks of development.

We said no to all of it. The schema survey found 263 pre-built views that already flatten the joins, eight of which carried everything the CRM needed. The volume is a nightly chain rather than a stream. The mapping is stable. So the answer was a managed sync reading those views through an agent inside the client’s network, with nothing of ours in the data path.

That build backfilled 20,004 orders reaching back to July 2020 along with 38,559 order lines, across 86 mapped fields and five objects, on eight jobs that run in a fixed order every weekday evening. The only code anyone wrote is the scheduler that chains those jobs, because a parent record has to land before the records that point at it. The full account is here, alongside the NCR CounterPoint page.

The tell was that nothing in the requirement needed a decision made at runtime.

Two engagements show the other side, and neither is really about volume.

A publisher keeps books, subscriptions and pricing in Naviga and runs its sales desk in HubSpot. Discovery tested every endpoint against live responses rather than documentation, and three answers settled the design. There are no webhooks for that scope. Customer records return a create date and no modification date, so a polling job has no changed since call to make. Subscription reads are per customer with no date filter at all.

Nothing packaged can be built on that. What we built discovers changed customers by walking identifiers forward from a saved checkpoint and comparing payload hashes, caps each order run at a 24 hour window so an outage cannot become an unbounded batch, and queues associations that fail to resolve for a repair pass a quarter past the hour. Seven flows, each with its own lock, checkpoint and run record. The middleware is here.

A senior living operator records every enquiry, tour and move in Yardi Voyager. The senior housing interface is SOAP, and it is a fixed contract: no webhooks, no changed since push, and no operation that sets a prospect’s status. Email cannot be the identity key, because family members share an address. The source also carries fields that must never reach a marketing system, so the mapping was built outward from an exclusion list rather than from the schema.

That became a lakehouse inside the operator’s own tenant, holding about 72,000 contacts and 45,000 deals and reconciling 133 properties on every run, with four safety gates between a staged change and a write. The architecture is here.

Both were unavoidable for the same reason. The source could not say what changed, so we had to build the memory. That is the cost people do not price in when they compare a packaged tool against a service, and it is why question five is the one that actually decides.