What we build in HubSpot

What it is, and where it sits

HubSpot is the CRM we encounter most in businesses between 20 and 200 people. Its API is genuinely good, its webhooks are dependable, and its object model — contacts, companies, deals, tickets, custom objects — maps cleanly onto how most businesses think.

Its own workflow tool is capable within HubSpot's walls. The builds we are asked for are almost always the ones that cross those walls.

What we build in it

• Lead capture, deduplication and routing from every inbound source
• Enrichment on creation — company size, industry, technology, funding
• Two-way sync with accounting so deal and invoice state agree
• Deal-stage-triggered orchestration across project, finance and document systems
• Quote and proposal generation from deal data
• Consolidated reporting joining HubSpot with ad platforms and delivery systems
• Data hygiene — continuous deduplication and property normalisation

How it is priced

You pay HubSpot directly. The relevant question for an automation project is which tier you are on, because API access and workflow features are gated by tier, and custom objects require Enterprise.

Check this before scoping. Discovering mid-build that the integration needs a tier upgrade is an avoidable and irritating surprise. We will ask which tier you hold on the first call.

When it is the right choice

The question here is not whether to use HubSpot but where to put the logic. Our rule:

• Inside HubSpot — anything only touching HubSpot data: lifecycle stages, internal notifications, property calculations, simple sequences. Native workflows are fine and your team can maintain them.
• Outside HubSpot — anything crossing a system boundary, anything needing real error handling, anything with logic complex enough that a person should be able to read it in one place.

Businesses that put cross-system logic inside HubSpot workflows tend to end up with sixty of them, no documentation, and no way to see the whole picture.

Limits worth knowing before you commit

• Tier gating. Several API capabilities and custom objects require higher plans.
• API rate limits are workable but need respecting on bulk operations; a naive migration script will hit them.
• Native workflows have no real error handling. If a step fails, it often just fails, quietly.
• Association complexity. The many-to-many relationships between objects are powerful and easy to model badly, which surfaces later as unreliable reporting.