
Your event went viral. Your bill should not.
We like usage-based pricing. We do not like pricing that turns audience behavior into an uncontrollable cost.
Imagine a 40-person meetup gets reposted by a creator with eight million followers. The event page suddenly receives 100,000 visits. Tens of thousands of people click the Add to Calendar Button.
That is a successful campaign. It should not feel like a billing incident.
Several major alternatives connect at least part of their pricing to audience interaction: button clicks, calendar adds, registrations, attendees, or a similar engagement metric. The exact name changes. In those models, your audience can influence your bill.
Add to Calendar PRO takes a different approach.
ποΈ We like usage-based pricing - when you control the usage
We are not against pay per use. We are big fans of it when the billable unit is clear, forecastable, and controlled by the customer.
Better ics, for example, meters calendar operations. Add to Calendar PRO also has a usage-based element: plans include a defined number of new events, and customers who enable Auto-Scale can create additional events at a published per-event price.
The important difference is who makes the billable decision.
With Add to Calendar PRO, you decide when to create an event. You decide whether to enable Auto-Scale. Clicks, signups, attendees, team members, and user actions remain unlimited. The operator controls the meter before the cost occurs.
| What happens | When interactions are the meter | With Add to Calendar PRO |
|---|---|---|
| One campaign reaches 100 times more people | The bill or required tier can grow | It is still one created event |
| The same person opens or clicks several times | Each interaction may consume an allowance | Repeated interaction is not a billing unit |
| Your team creates another event | It may not be the main cost driver | The operator knowingly uses event capacity |
That is predictable usage-based pricing. Audience behavior is not.
π« A success tax creates the wrong incentive
Consider three deliberately extreme examples:
- A local charity event gets picked up by national news. Traffic rises by 500 times overnight, but the organizer still has one event and the same small budget.
- A university publishes an emergency schedule update. Students, parents, and newsrooms open the page repeatedly because the information matters right now.
- A product-launch email is forwarded across a global company. One person may open it on a phone, click again on a laptop, and test two calendar options before saving.
Those interactions do not all represent new value for the organizer. A click is not necessarily an attendee. A repeated click is not a second customer. Viral reach should not create an open-ended financial risk.
We do not want customers asking, βCan we afford for this campaign to succeed?β
π Scaling public traffic is our engineering problem
Serving popular public event content has a cost, but that does not mean every request needs to become a line item on a customer invoice.
Public assets can be cached. A global CDN can serve repeated requests close to users. Efficient software can make the hundred-thousandth view dramatically cheaper than the first. Building that delivery layer well is our responsibility as the platform operator.
Our philosophy is simple: when scale can be handled efficiently on our side, the risk should stay on our side. Customers should be comfortable promoting an event as widely as possible.
No click counter anxiety. No surprise success tax.
π Technology claims should be verifiable
Fair pricing is only useful when the underlying technology can carry the traffic.
Our Add to Calendar Button grew from an open-source project. Its npm package usage and public jsDelivr statistics can be inspected by anyone. At the time of writing, jsDelivr reported more than 170 million monthly requests for the package - a scale of millions of requests per day.
Those are CDN requests, not unique users, button clicks, Add to Calendar PRO customers, or proof of reliability. That distinction matters. They demonstrate publicly verifiable package traffic instead of asking you to trust a closed claim.
That transparency complements pricing designed not to punish successful campaigns.
β The bottom line
Add to Calendar PRO charges for a resource customers can control: the number of new events they create. We do not charge for the attention those events earn.
It reflects how we believe event technology should work: capable, transparent, forecastable, and fair.
Review our pricing or start a full-featured trial. Then promote the event without worrying that success itself will become the problem.

