A custom object feels like the grown-up answer. Your business has a thing that HubSpot does not have a tab for, so you make one. It is the move that looks like architecture.
It is usually the move that costs the most.
Native objects arrive with things you cannot see until they are missing. Association types are already defined. Reporting already understands them. Integrations already map to them. Workflow actions already exist for them.
A custom object arrives with none of that. Every relationship it has to anything else is a thing you define and then maintain. Every report on it is one you build. Every integration that touches it needs custom mapping. The object itself takes an afternoon. The connective tissue takes the rest of the quarter, and it never stops needing attention.
Before anyone proposes a custom object, do this in order.
List the data you actually need. Not the screens you imagine. The records, the fields, and what has to be reported on.
Check the native catalog for each one. Contacts, Companies, Deals, Leads, Tickets, Orders, Line Items, Payments, Subscriptions, Quotes, Carts. The transactional half of that list is the half most teams have never looked at, which is why it keeps getting rebuilt by hand.
Use custom properties liberally. They are free, they live on native objects, and they fragment nothing. A native object with twenty custom properties is a normal, healthy setup. A custom object with twenty properties is a silo.
Only then, propose a custom object for what genuinely does not fit.
If a workflow you are imagining would rebuild HubSpot's standard functionality inside a custom object, you are building the wrong thing.
Recurring revenue is the clearest case. Teams build a custom "Membership" or "Contract" object, then build workflows to track renewal dates, then build reports to sum monthly value. Subscriptions does all of that already, and it is wired into the rest of the platform.
The same goes for finalized purchases, which are Orders; for partial payments, which are Payments; and for per-product detail, which is Line Items on whatever it hangs off.
There is a real case, and it is narrower than it looks. A custom object earns its place when the shape is genuinely novel to your business and a named team will own it for years. A clinical procedure record. A course enrollment. Things with their own lifecycle that no native object is pretending to be.
That is the bar. Novel shape, long-term owner. Not "we could not find where to put it in an afternoon".
Most accounts we look at have at least one custom object doing a job a native object does better, built early by someone reasonable who did not know the native catalog went that deep. It is not a competence problem. The transactional objects are genuinely under-documented compared to Contacts and Deals.
The fix is usually cheaper than people expect, and it is almost always worth doing before adding anything else on top.