HubSpot's AI Breeze,reimagined.
Turning a silent $50/month upgrade into a controlled product decision.
- Type
- Concept build
- Product
- HubSpot Starter and Breeze
- Role
- Product strategy, interaction design, interface design, full-stack build and AI integration
- Scope
- AI adoption, billing transparency, human control and failure recovery
- User
- Founder-operators and marketing or operations leads using HubSpot to run a growing B2B company
- Status
- Working, deployed full-stack demo
The problem
The upgrade that can cost the product the customer.
The commercial risk was not the extra $50. It was making expansion feel like a trap.
In the original flow modelled for this concept, a Starter customer could exceed a 1,000-marketing-contact limit while completing an ordinary task. Moving into the next contact band added $50 per month, but the consequence was easy to miss until the user was already at the decision point.
For the user, this created three problems:
- They did not have a clear mental model of which contacts counted toward the limit.
- They could not see the exact financial consequence before acting.
- They had no useful path for resolving the problem without accepting the upgrade.
For HubSpot, the same interaction created a different set of risks:
- An accidental upgrade could become a support request, refund or chargeback.
- A revenue event could damage trust before a renewal conversation.
- Customers could respond by avoiding marketing contacts, limiting activation or moving work into another tool.
- Breeze could appear present in the product without becoming a dependable part of the workflow.
Product strategy
Protect expansion revenue without hiding the consequence.
The goal was not to prevent an upgrade. It was to make the upgrade intentional.
Removing the upgrade would have ignored HubSpot’s commercial model. Making the warning louder would have treated the symptom without helping the user resolve it.
I defined the product problem more narrowly:
How might HubSpot preserve a valid expansion path while giving customers enough evidence, control and recovery to make the decision consciously?
That produced three requirements.
01
Make the consequence concrete
The interface needed to show the current quota, the projected quota, the additional monthly cost and when the billing change would take effect.
02
Offer a useful alternative
The product needed to help users remove low-value records before asking them to pay for more capacity.
03
Keep consequential actions under human control
Breeze could identify and explain cleanup opportunities. It could not decide which records should be deleted or perform an irreversible action without approval.
Decision log
The interface changed because the decision model changed.
I used the product’s business rules to define where AI could help—and where it could not.
01
Decision
Lead with remediation, not the upgrade
Why it mattered
I gave “Optimise Database” equal decision weight to accepting the paid tier.
This introduces a trade-off: the flow may delay some immediate expansion revenue. However, an intentional upgrade is more defensible than revenue generated through confusion.
Business implication
Protect customer trust while preserving the commercial upgrade path.
02
Decision
Let the application own the numbers
Why it mattered
Quota totals, contact counts, billing thresholds and upgrade timing remain deterministic.
The model does not calculate the price or decide whether the account has exceeded its allowance.
Business implication
Financial information remains testable and consistent even when the AI output is imperfect.
03
Decision
Let AI recommend, not execute
Why it mattered
Breeze identifies potentially low-value contacts and explains why they may be safe to review.
It does not preselect records, approve deletion or change marketing status by itself.
Business implication
AI reduces manual effort without taking authority away from the operator.
04
Decision
Show the full triage
Why it mattered
I used a dedicated database review rather than presenting a single AI-generated summary.
Users can inspect the records, categories and reasons before taking action.
Business implication
The recommendation becomes evidence the user can challenge, not an instruction they are expected to trust.
05
Decision
Add friction where the risk increases
Why it mattered
Typing the deletion count adds work, but it also separates a permanent action from the product’s routine interactions.
Business implication
A small amount of deliberate friction can prevent expensive recovery work, support contact and loss of confidence.
06
Decision
Design recovery before the error occurs
Why it mattered
Undo was not added as a final polish detail. It was part of the interaction model from the beginning.
Business implication
Recovery turns an error from a customer incident into a manageable product state.
From strategy to build
A working product, not a handoff.
The build tested whether the interaction logic could survive outside a design file.
I built a functioning, pixel-matched CRM environment with the complete contact-limit flow and a Gemini-backed Breeze integration.
Building the product changed several design decisions. Static screens could imply that the quota, AI classification and deletion flow worked. A functioning prototype required each state to be defined.
That included:
- Calculating the quota before and after the proposed action.
- Maintaining the user’s selected records across the flow.
- Separating AI recommendations from deterministic product facts.
- Defining what happened when no useful cleanup opportunities were found.
- Handling confirmation, deletion, status feedback and Undo.
- Keeping the new interaction consistent with the surrounding HubSpot product patterns.
This closed the gap between an attractive concept and an interaction that engineering could evaluate.
AI architecture
The model assists with judgment. The product retains authority.
The architecture was divided according to consequence, not technical novelty.
Deterministic product layer
The application controls:
- Contact and quota counts
- Billing thresholds
- Upgrade timing
- Record selection
- Confirmation state
- Deletion
- Undo
- Final system status
These behaviours must be predictable, testable and auditable.
Bounded AI layer
Gemini supports:
- Identifying potentially low-value records
- Grouping contacts into review categories
- Producing a short reason for each recommendation
- Helping the user understand where cleanup effort should begin
Its output informs the decision. It does not become the decision.
Safety layer
The interface provides:
- No preselected destructive actions
- Record-level evidence
- Human review
- Explicit approval
- Type-to-confirm friction
- Clear success feedback
- A limited recovery path
If the AI output is not useful, the user can continue reviewing the database manually. The model cannot block the underlying task or execute it independently.
01
Lead with remediation, not the upgrade
Business implication
Protect customer trust while preserving the commercial upgrade path.
02
Let the application own the numbers
Business implication
Financial information remains testable and consistent even when the AI output is imperfect.
03
Let AI recommend, not execute
Business implication
AI reduces manual effort without taking authority away from the operator.
04
Show the full triage
Business implication
The recommendation becomes evidence the user can challenge, not an instruction they are expected to trust.
05
Add friction where the risk increases
Business implication
A small amount of deliberate friction can prevent expensive recovery work, support contact and loss of confidence.
06
Design recovery before the error occurs
Business implication
Recovery turns an error from a customer incident into a manageable product state.
Next project
RenewalPipeline
View case study→