Okay, so I'm coming at this from a cloud cost and observability angle, but I think the principle is the same: arbitrary platform limits that don't align with your usage pattern are a huge growth tax.
We're running a SaaS product on AWS, and our growth model is built around a generous free tier. We use HubSpot's free CRM to manage those leads. The problem hit when we crossed 2,000 contacts. HubSpot's "marketing contact" designation kicked in, and suddenly, basic automation and email for anyone over that limit requires a hefty upgrade. This isn't about sending bulk newsletters—it's things like automated onboarding sequences for free users. Our unit economics for free users can't absorb a per-contact cost from the CRM itself.
It feels like hitting a provisioned throughput limit on a DynamoDB table you thought was on-demand. The cost curve jumps vertically, not gradually.
Has anyone else faced this with a product-led growth model? What did you do?
I've been sketching out alternatives, but the switching cost is real. We have all our forms and simple workflows there. I'm evaluating:
1. **Biting the bullet and upgrading.** But then I need to forecast this cost like a cloud bill, which feels wrong for a CRM contact list.
2. **Segmenting contacts.** Making only "qualified" leads marketing contacts. This adds operational complexity—like managing tags and lifecycle stages just to route around a limit.
3. **A hybrid setup.** Keep HubSpot for sales pipeline, but use a cheaper service (like SendGrid or AWS SES with a simple frontend) for transactional and onboarding emails to free users. Then sync data back? This is where my observability brain lights up with "data pipeline fragility."
```json
// This is the kind of logic we'd have to add everywhere
"if contact.is_free_user && total_marketing_contacts >= limit":
route_to_external_system()
else:
use_hubspot_workflow()
```
I'm curious about real-world reliability of those syncs. Did you build a custom sync with the HubSpot APIs, or use a tool like Zapier? How do you handle the observability—alerting on sync failures or contact count thresholds?
The core issue is that our *usage* (user signups) and our *cost* (marketing contacts) are now misaligned. In cloud, I'd solve this by moving to a truly usage-based service. Is there an equivalent in this space, or are we just choosing a different set of constraints?
cost first, then scale