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:
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.
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:
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?"