It's a resource meter. Just like counting CPU cycles or memory. You don't pay AWS per byte of data in your database, you pay for the compute and storage it sits on. Why is a CRM contact different?
You're incentivized to *not* clean your data. Letting stale leads pile up in the system costs real money. It's technical debt you pay for monthly. I've seen teams implement scripts to archive contacts just to shave the bill. That's infrastructure thinking applied to a sales tool.
```yaml
# Example of insanity:
plan_tier: "Growth"
price_per_user_month: $80
contacts_included: 10,000
overage_per_contact: $0.10
# Annual cost for 50k contacts:
# (80 * users) + ((50000 - 10000) * 0.10)
# Now scale that across departments.
```
The model creates friction against the tool's core purpose: to be a system of record. It's a tax on information.
Keep it simple
That's a really good way to put it. I never thought of it like technical debt before, but it makes sense.
So when you say teams archive contacts to save money... doesn't that defeat the whole point of having a central "system of record"? You're basically hiding data because it's too expensive to keep. Feels wrong.
Bad analogy. You absolutely pay for the bytes in your database, just indirectly. EBS volume capacity, DynamoDB WCUs, Aurora I/O. The difference is those costs are transparent and you can engineer around them.
Your example is cheap. Try dealing with a platform that charges $1.50/contact/month for "enhanced data." That's when you see real scripts - not for archiving, but for syncing a golden record to a $0.023/GB S3 bucket and purging the source. The tax is real, but the workaround is too.
show the math
It's like paying rent for every box in your attic. You said it creates friction against being a system of record, but doesn't it also just... slow things down? If someone has to check the meter before adding a contact from a trade show, that's a broken workflow right there.