HubSpot's pitch is "no-code for 80%, low-code for 15%, custom for the remaining 5%." That last 5% is where RevOps custom dev pays for itself — it's the difference between a marketing platform you configure and a product surface your team actually operates. Here's a guided tour of the patterns worth knowing if you're evaluating HubSpot as a long-term platform, or scoping a migration off WordPress.
HubSpot Projects: serverless functions for RevOps
HubSpot Projects is HubSpot's serverless functions product. It deploys via the HubSpot CLI and scales automatically. The typical use cases:
- Webhook receivers. External system sends an event to HubSpot; a Project function processes it, updates CRM records, and triggers a workflow.
- Custom form processors.When a native form submission isn't enough — conditional validation, enrichment against a third-party API, custom lead scoring — a Project function runs as part of the submit pipeline.
- Third-party API bridging.Pull data from an internal API, map it into HubSpot's shape, and update records on a schedule.
- Background jobs for heavy operations. Long-running imports, reconciliations, or cleanup tasks that would time out a synchronous request.
The developer ergonomics are clean: TypeScript-friendly, version-controlled, CLI-deployable, with native integration into HubSpot's authentication and logging surfaces. If you've used Vercel Functions or AWS Lambda, you'll feel at home.
Custom CRM objects: modeling your business entities
HubSpot ships with contacts, companies, deals, and tickets. For most B2B motions that's enough. When it isn't — when your business has facilities, contracts, assets, policies, engagements, or any other first-class entity HubSpot doesn't model natively — custom CRM objects solve it.
A custom object is API-accessible, reportable alongside contacts and deals, and lifecycle-aware. You can associate custom objects with contacts and deals to model relationships that matter to your team. For example: a facilities-management company might add a "Facility" custom object associated with contacts (managers) and deals (contracts), making every rep's account view show the right operational context.
The discipline here is to model sparingly. Every custom object adds maintenance surface; the tipping point is around 3-4 custom objects, above which the CRM starts to feel bespoke. That can be correct — but it should be a deliberate decision.
HubDB: structured tables that drive pages
HubDB is HubSpot's structured-table product. Think of it as a small relational database with a row-and-column shape, API-accessible, that can drive dynamic pages automatically.
HubDB is the right answer for content that benefits from a row-and-column shape:
- Location directories (every row is a location; dynamic URL per location)
- Resource libraries (every row is a download; filter UI by category)
- Team pages (every row is a person; sortable + filterable)
- Event listings (every row is an event; expiration-aware)
- Integration marketplaces (every row is a partner; dynamic per-partner page)
For content that's long-form and unstructured (blog posts, detailed case studies), HubDB is the wrong tool. Use HubSpot's native blog and landing-page surfaces for those.
Custom modules: the content-team multiplier
Custom modules are reusable UI blocks with typed fields. They are the primary investment that separates a good HubSpot implementation from a fragile one.
A well-built module has: clear field labels, sensible defaults, field-level validation, documentation visible to the author, and responsive behavior baked in. A badly-built module has: free-text HTML fields, unclear field names, no documentation, and relies on the author to know which styling class to use.
The test: hand the module to a marketer who wasn't involved in building it and watch them try to use it. If they reach for the developer after 30 seconds, the module has bad ergonomics. This is worth iterating on during Phase 3 of a migration, not leaving for post-launch.
Public apps: when you need to ship an integration to others
Everything above is internal to your HubSpot portal. Public apps are the way to ship a HubSpot integration that other organizations install in their own portals. Same underlying tech (Projects + APIs), different distribution: OAuth-based authentication, submission to the HubSpot App Marketplace, per-customer credential management.
Public apps are a product-engineering project, not a RevOps project. If you're considering one, treat it like any SaaS product — scope UX, support, pricing, and maintenance before writing code.
API + webhook integrations
The HubSpot API is broad, well-documented, and rate-limit-aware. Standard patterns for integration:
- Salesforce sync — bidirectional contact and deal sync. HubSpot ships a native Salesforce integration that covers 80% of use cases; custom dev handles the remaining field mappings and conflict-resolution logic.
- Data warehouse exports — scheduled Projects that push CRM snapshots into Snowflake, BigQuery, or Databricks for attribution modeling and executive reporting.
- Internal system bridges — an ERP (NetSuite, SAP), billing platform (Stripe), or ops tool needs to share state with the CRM. Projects-plus-webhooks is almost always the cleanest pattern.
- Event streaming into HubSpot — product telemetry from your own SaaS product that enriches the CRM profile. Use the Custom Events API rather than force-fitting into contact properties.
The discipline: start with the no-code path
Every time you're tempted to write custom, ask whether a native HubSpot capability solves 80% of the need. In almost every case the answer is yes, and the remaining 20% is usually cosmetic. The mistake most teams make when they first earn custom-dev capacity is to use it everywhere — which undermines the platform's no-code promise and creates maintenance debt that compounds.
The right rule of thumb: any custom build must save at least 10x its maintenance cost in team hours per year. If it doesn't, use the no-code path and live with the 80% solution.
What's next
If you're scoping a WordPress-to-HubSpot migration and wondering which extension patterns your team will need, our free migration guide walks through the 6-phase playbook with decision points for each custom-dev investment along the way. Or if you'd rather talk through your specific situation, scope the engagement with us directly.