In our consulting projects, we experience it regularly: as soon as a process deviates from the HubSpot standard, the question arises as to whether you are "leaving the platform". The concern is justified. In-house developments around SaaS platforms have left their mark on many companies, from high maintenance costs to blocked updates.
This is precisely why it is important to classify custom cards: They are not an in-house development alongside HubSpot, but a standard-compliant extension within the platform.
Custom Cards (technically correct: App Cards, built via HubSpot UI Extensions) are tailor-made user interfaces that appear directly where your employees work every day: on the customer or deal view and in the service area of HubSpot. They display exactly the information and actions that are needed for a specific process.
In this article, we are deliberately talking about private custom cards, i.e. those that run exclusively in your HubSpot account - the rule for internal company solutions and completely sufficient in the vast majority of cases. Public cards for the HubSpot Marketplace are a different category with additional requirements (such as multi-client capability, often also components outside of HubSpot) and are not the topic here.
Not for every process. But for those where the HubSpot standard requires more clicks, tabs and explanations than is good for day-to-day business. Three typical triggers from our projects:
- Guided processes: Employees should go through a customer-specific process step by step without having to have training in their heads.
- Condensed view: Information from different sources (HubSpot objects, external systems, calculations) should appear in one place.
- Shortened click paths: Actions that normally require five to seven clicks should be triggered with a single click.
In all three cases, the custom card is not a cosmetic intervention, but a measurable investment in efficiency. Employees become productive more quickly, error rates fall and onboarding is shortened.
It's not about standard or custom. It's about: standard as everyone gets it, or standard as your company needs it.
Both are safe ways. The HubSpot standard is available quickly, but is the same for all companies. A custom card adapts the standard to your processes while remaining fully part of the HubSpot platform: updates, security and support continue to function as usual.
What custom cards are not: an in-house development outside of HubSpot. This is precisely the variant that management rightly respects, and it is precisely this variant that we avoid.
For IT Managers: What Custom Cards Mean from a Technical Perspective
Custom Cards are developed using HubSpot’s official UI Extensions SDK in React/TypeScript and embedded within a private app. They run within the HubSpot infrastructure, utilize the official APIs, and adhere to the HubSpot Design System. Authentication, permissions, data access, and API limits are managed through HubSpot’s own mechanisms. There is no separate server, no separate database, and no separate identity management layer. If external systems are connected, this is done via controlled API calls within the app.
Source: HubSpot Developer Documentation, “Create UI extensions with React”.
This is the point that counts for the management. With in-house developments outside of a platform, every platform release means a potential risk: interfaces change, integrations break, compatibility must be actively checked.
This works differently with custom cards, for three reasons:
-
HubSpot releases do not break custom cards. They use the official, documented extension points of the platform. HubSpot actively maintains these and guarantees their stability via the official developer program.
-
The app is versioned and traceable. Every change is documented in the code versioning. A new version of the card is deployed cleanly, older versions can be rolled back if necessary.
-
Maintenance costs are predictable and low. As a rule, an annual review is sufficient to install SDK updates and minor adjustments. There is no "permanent maintenance site" as with classic in-house developments.
To be honest: custom cards are not a panacea. Three points should be included in every decision:
- They do not replace a bad process. If the underlying process is unclear, even the best card won't help. First clarify the process, then build the card.
- You need a clear added value per card. Every card that is not actively used is complexity without value. We recommend starting with one or two clearly defined cards and expanding them as soon as the benefits become apparent.
- They require Sales or Service Hub Enterprise licenses. Custom cards are part of the platform in the corresponding editions and do not incur additional costs, but require the appropriate license level.
For IT Managers: What Maintenance Means in Day-to-Day Operations
In production, we maintain Custom Cards just like any other app asset: regular SDK updates (the HubSpot UI Extensions SDK is under active development), logging via HubSpot’s own Logger API, monitoring of API limits, and a documented deployment process. Since Cards reside in a private app, permissions, visibility, and scopes are clearly traceable. We proactively communicate security-related SDK updates and schedule them during the agreed-upon maintenance windows.
Anyone who equates custom cards with "we are leaving the standard" is comparing two different things. The correct comparison is: HubSpot standard for all versus standard that is precisely tailored to your processes. Both remain within HubSpot, both use the official platform infrastructure, both are maintained identically.
The most important question when choosing a marketing platform is not "Which system offers the most features?", but "Which system can our team actually use to create value over the next three years - consistently, data-based and AI-supported?"
