Why this is worth writing down
I implement HubSpot for a living, so read this with that in mind. The reason to write it anyway is that the alternative is discovering these things in month four, when the data is already in and the decision is expensive to revisit. None of what follows is a reason not to use HubSpot. All of it is a reason to go in knowing which walls are where.
Editing in the UI leaves no trace
A module, a template or a workflow action can be changed directly in the portal by anyone with permission, and there is no diff, no review step, and no history explaining what changed or why. For a one-person portal that is convenience. For a team it is a shared document everyone is slightly afraid to touch. This one is fixable rather than inherent, and the fix is putting the portal under version control, which is a whole subject of its own.
Reporting has a ceiling, and you will find it
The custom report builder covers more than people expect and then stops. The limits show up around reporting across several custom objects at once, attribution modelled the way your business actually attributes rather than the way the tool does, and anything needing a calculation over historical states rather than current values. The honest answer at that point is not a better report; it is getting the data into a warehouse and modelling it there. Which is fine, but it is a second system, and it belongs in the plan rather than in the surprise.
Costs scale on axes you do not fully control
Contacts accumulate whether or not anyone is doing anything with them, and seats grow as a team grows. Both push the bill in a direction that has nothing to do with whether you are getting more value this year than last. It is manageable with a contact policy and a seat review, but it needs someone to own it, and by default nobody does.
The CMS is a real commitment
HubSpot CMS is genuinely good at the thing it is for: marketing pages that marketers can edit, wired into the CRM without an integration in between. The commitment is that templates are HubL, modules are HubSpot modules, and none of it is portable. Moving a site off HubSpot means rebuilding the front end, not exporting it. Worth it when the CRM coupling is the point; expensive when the site was put there because it was convenient at the time.
Workflows are easy to write and hard to reason about
Building a workflow takes minutes. Understanding, two years later, why a contact is in a state nobody intended takes considerably longer, because the answer is usually four workflows interacting through properties none of them own outright. HubSpot gives you enrolment history, which helps, but it does not give you anything resembling a call graph. The discipline that saves you is boring: one owner per property, and a naming convention that survives the person who invented it.
What it is genuinely good at
The CRM as an object layer is the strongest part of the product and the least discussed, because it is not what the marketing is about. Everything else reads from one set of records, which is precisely what the assembled-from-parts alternative never manages. Setup is fast, the API surface is broad and well documented, and the gap between what a marketer can do alone and what needs a developer is wider in HubSpot's favour than in most of its competitors.
The question worth asking instead
Not whether HubSpot is good, which is unanswerable, but whether the thing you need it to do is the thing it is shaped around. If the answer is one set of customer records that marketing, sales and service all act on, it is hard to beat. If the answer is heavy custom reporting, a product-led data model with millions of events, or a website that happens to need a form, you are buying the wrong part of it, and the mismatch will show up as cost.