HubSpot has a new pricing architecture.
Kunal Thadani recently published an exhaustive teardown of it, based in part on conversations with David Barron, who spent more than eleven years at HubSpot across sales, product, operations, and pricing and packaging.
The history matters.
Over time, HubSpot grew from one product into multiple Hubs, editions, seat types, usage limits and dozens of add-ons. Individual packaging decisions could make sense. Collectively, they created something customers—and apparently HubSpot employees—needed increasingly more help to understand.
Thadani sums up one of the fundamental problems beautifully:
Customers experience workflows. Companies package org charts.
Consider his example.
A customer uses automation to route incoming sales leads to the appropriate person. Then the company wants to perform essentially the same action with an incoming support ticket.
To the customer, it is the same job: something arrives; route it to the right person.
Historically, HubSpot could treat those as different jobs because one belonged to Sales and the other to Service.
The customer sees a workflow.
The software sees a Hub.
The new pricing addresses that – sort of.
HubSpot is simplifying the buying decision.
Instead of assembling different editions of multiple Hubs, its new Customer Platform pricing moves toward account-level editions. Seat types have been simplified. Add-ons have been reduced. Seats price human access while credits increasingly price work performed by software and AI.
There are some smart pricing ideas here.
But there is an important distinction between simplifying how software is priced and simplifying how software works.
HubSpot simplified how customers buy its complexity. It did not eliminate the complexity.
Look underneath the new pricing and the same conditions remain.
- HubSpot’s current documentation says seats determine which tools users can access, while permissions determine what they can do within those tools.
- Workflow capabilities still vary according to subscription and object.
- Custom-object workflows require Enterprise.
- Campaign and social-post workflows require Marketing Hub Professional or Enterprise.
- Leads require Sales Hub Professional or Enterprise.
- Feedback and tickets require Service Hub Professional or Enterprise.
- Quotes, orders, credit memos and contracts have their own Revenue Hub requirements.
Really?
Even something as seemingly straightforward as routing a support ticket has conditions around subscriptions, paid seats, team membership and eligibility.
The price may be easier to understand. The operating rules haven’t disappeared.
It reminds me of buying into an HOA.
The brochure is beautiful. The membership options are clear. You sign the papers.
Then you discover the covenants are 87 pages long.
My comment on Kunal’s article:
“HubSpot simplified how customers buy its complexity. It did not eliminate the complexity.
Like an HOA, they've simplified the brochure and membership options. The covenants are still 87 pages long.”
David Barron replied:
“The goal is better than before, it’s a journey.”
And that may be the most revealing part of the conversation.
Pricing can change. Architecture is harder.
HubSpot's complexity wasn't created by a bad pricing page.
It accumulated as products, features, Hubs, permissions, objects, seat types, workflows, integrations, and exceptions accumulated.
Changing how those things are packaged may make the buying decision easier.
It doesn't change why the complexity exists.
That's the distinction that matters.
Pricing is something the customer encounters when buying the software.
Architecture is something the customer lives with while using it.
And increasingly, it's something AI has to live with, too.
AI is exposing architecture.
For years, much of SaaS answered new business requirements by adding another application, another module, another integration or another specialized tool.
Then we connected everything.
Then we built dashboards to reconcile everything.
Then we built more technology to manage the technology connecting everything.
We've spent an extraordinary amount of technology solving problems created by technology.
AI makes the consequences harder to ignore.
An AI agent is only as useful as the context available to it.
If customer information is spread among CRM, marketing automation, support, project management, documents, email and half a dozen other systems, AI doesn't magically make those silos disappear.
It has to navigate them.
- Which system has the authoritative record?
- Which permissions apply?
- Which information is current?
- Where should the agent write something back?
- What happens when one system disagrees with another?
Those aren't fundamentally AI problems.
They're architecture problems that AI has made impossible to ignore.
A different architectural path.
Venntive was designed differently.
From the beginning, it was conceived as a unified system, with capabilities added to a common foundation rather than separated into functional silos.
One login.
One interface.
One unified database.
One source of truth.
That wasn't an accident.
For those looking ahead, it wasn't necessary to know exactly what the next technology would be. The point was to build an architecture capable of accommodating what came next.
The specifics changed.
Automation became more sophisticated. Data became more important. Machine learning expanded what software could infer. AI can now understand context and increasingly take action. MCP and agents are extending that further.
But the architectural requirement has remained remarkably consistent:
Give the business one coherent foundation that can evolve as technology evolves.
That's why today's AI moment matters.
AI doesn't make fragmented architecture irrelevant. It makes the consequences of fragmentation more obvious.
An AI agent still needs context. It needs reliable data. It needs permissions. It needs to know which information is authoritative and where its actions belong.
Those requirements are much easier to satisfy when the business isn't already divided among a collection of systems that each know only part of the story.
The technology changed.
The value of building for what comes next did not.
The future shouldn't require another rebuild.
MCP and agents introduce a new participant into business operations: software that can increasingly perform work rather than simply help a human perform it.
But the underlying requirements aren't particularly new.
Context.
Permissions.
Reliable data.
Governance.
A clear understanding of relationships.
A reliable place to record what happened.
People needed those things before AI.
Agents need them now.
Whatever comes next will need its own version of them, too.
That's the point of building with an eye toward the future.
Not predicting precisely which technology comes next.
Building an architecture capable of accommodating it when it arrives.
Which brings us back to HubSpot's pricing redesign.
Simplifying a complicated pricing system to make it easier to purchase is certainly better...
But pricing wasn't the underlying problem.
The architecture created the complexity.
The pricing exposed it.
And that leaves a larger question for any company evaluating its business technology:
Are you choosing software for what your business needs today, or an architecture capable of accommodating what your business will need next?
Because there will always be a next.
Build for what comes next.
If your business has outgrown a collection of disconnected tools—or you're thinking about how AI and agents fit into your operations—the place to start isn't another app.
Start with the architecture underneath them.
Want to see how Venntive approaches it?
Let’s talk!
What did you think of this article? Tell me in an email I read and respond to every email. lksugarman@venntive.com
Excellent — worth my time (5/5)
Useful — gave me something to think about (3/5)
Missed the mark (1/5)