Just saw the news about Salesforce raising prices again. As someone managing cloud costs, this makes me nervous 😅. Their platform is powerful, but the lock-in feels heavy.
When I build in AWS, I use Terraform to keep control. If I were to model even a simple external service connection, I'd want it defined as code. Makes me wonder: for a CRM, what would a "portable" setup even look like? Is the ecosystem and data gravity worth the rising cost?
For example, if I had to integrate *something* with our VPC, I'd want the security group rules documented and versioned.
```hcl
resource "aws_security_group_rule" "allow_crm_api" {
type = "egress"
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["203.0.113.0/24"] # Hypothetical CRM IP range
security_group_id = aws_security_group.app.id
}
```
This is just network access, not the actual service. But with Salesforce, you can't define the *service itself* like this. You're buying into their entire world. Are the use-case assumptions (like needing deep customization and all-in-one suite) still scoring high enough to justify the premium and lock-in?
Hey, I'm actually a junior cloud engineer at a small logistics firm. We moved our custom order tracker off a shared host to AWS last year, and I've been learning IaC with Terraform. We don't use Salesforce CRM, but we did trial it against a simpler platform.
Here's a breakdown from my limited, cost-focused view:
1. **Target Fit & Complexity:** If you need deep, custom workflows with tons of automation, Salesforce is built for that. But for a standard sales pipeline with contacts and deals, it's heavy. A platform like HubSpot Sales Hub felt 70% as capable for our basic needs.
2. **Real Pricing & Lock-in:** Salesforce list prices are one thing, but the real lock-in cost is custom objects and flows. Migrating that logic out is a huge manual project. With AWS and Terraform, my infrastructure is redeployable elsewhere. A basic HubSpot Sales Professional seat was about $90/user/month last I checked, versus Salesforce starting well above that before add-ons.
3. **Integration & Control:** Your Terraform example nails it. With Salesforce, you connect *to* their opaque environment. In AWS, I define the security group, the VPC endpoint, and the IAM role. I can see and version it all. Salesforce's integration is through their API, which is powerful but you manage zero infrastructure.
4. **Where It Breaks / Limitation:** The simplicity trade-off. If your team isn't technical, building custom objects in Salesforce with clicks is easier than me writing a DynamoDB schema and a frontend. But when you need to change a core process, you're often waiting on a Salesforce-specific consultant or digging through their documentation.
My pick? For a small team with a cloud-native mindset and a standard CRM use case, I'd look at a lighter SaaS tool (like HubSpot) and integrate it via API. You keep some agility and avoid the deepest lock-in. To make a clean call, tell us your team's technical comfort level and how custom your sales process really is.
That Terraform example hits on the core issue: you can codify the *perimeter*, but not the *logic*. I've worked on Salesforce integrations, and the lock-in is indeed in the custom objects, validation rules, and Apex code.
The "portable" CRM dream often lands on a headless platform. You might model your core entities (Contacts, Leads) in your own Postgres database, with an internal API, and use a service like N8N or Retool for the UI and simple workflows. It's more initial work, but you own the schema and the data pipeline.
But then you're rebuilding features Salesforce gives you for free, like their sharing model or real-time collaboration. It becomes a trade-off between engineering effort and ongoing license costs. For a company with a strong dev team, the math might start to shift.
Latency is the enemy, but consistency is the goal.