AddEvent: Building the Web's Leading Add to Calendar Service

If you've ever clicked an "Add to Calendar" button on a website or in an email and had an event land neatly in your Google Calendar, Apple Calendar, or Outlook, there's a decent chance that button was powered by AddEvent. It's the kind of product most people use without thinking about, which is exactly the point. AddEvent makes it effortless for businesses to get their events onto their users' calendars, and for those users to actually show up.

I spent nearly four years at AddEvent as a Senior Software Engineer, and in that time I got to work across nearly every part of the platform.

What AddEvent does

AddEvent is the most widely used add to calendar service on the internet and is trusted by thousands of companies and individuals. At its core, the platform helps businesses share events and get them onto people's calendars, but it's grown well beyond a simple button. The product suite includes add to calendar buttons and links for websites and emails, subscription calendars that keep users synced with ongoing schedules, embeddable calendar widgets, RSVP collection and tracking, event landing pages, analytics, and a developer API that powers custom integrations. It works across Google Calendar, Apple Calendar, Outlook, Office 365, and Yahoo, with automatic timezone and daylight saving time handling which, if you've ever dealt with calendar standards, you know is a deeper problem than it sounds.

What I worked on

In a small engineering team I had the opportunity to contribute broadly rather than being siloed into one area of the product. During my time with the company my work spanned nearly every aspect of the product, requiring me to interface with other teams to make sure all priorities were accounted for.

Some of the work I'm most proud of:

Contributing to the v2.0 architectural overhaul During my time at AddEvent, the team undertook a major version 2.0 overhaul of the platform. I was involved in the architectural planning and decision-making that shaped how the new system would be structured. This refactoring was intended to improve the performance of the app as well as our ability to continue supporting and improving it. Being part of those conversations, weighing tradeoffs, advocating for certain approaches, and ultimately committing to a direction as a team was one of the most valuable experiences of my time there. The decisions we made during that period became the foundation that the platform continues to build on to this day.

Stabilizing recurring events and event series If there's one area of calendar engineering that will humble you, it's recurring events. The concept is deceptively simple: "repeat every other Wednesday", but the implementation touches every edge case imaginable. Recurring rules (RRULEs) need to account for frequency, interval, specific days of the week, end conditions, and the interaction between all of these. Multiply that complexity across every major calendar provider, each of which interprets and enforces these rules slightly differently. The work was painstaking and detail-oriented, but it mattered. When thousands of companies depend on your platform to put events on people's calendars accurately, getting recurrence wrong isn't a minor bug it's a broken promise to every end user who trusted that the event would show up at the right time.

Enhancing the billing system with Stripe I also worked on enhancing AddEvent's billing system, including integrating Stripe's billing portal to give customers more control over their subscriptions. The Stripe billing portal gives customers a self-service experience for managing their plans including upgrading, downgrading, updating payment methods, and viewing invoice history without needing to contact support. For a SaaS platform with different plan tiers and rules, reducing billing friction directly impacts both customer satisfaction and retention. It's not glamorous work, but it's the kind of engineering that keeps a SaaS business running smoothly.

What I took away

Building for invisible reliability When your product works, nobody notices. When it doesn't, thousands of companies notice immediately. That kind of pressure shapes how you think about testing, edge cases, and defensive engineering. My time at AddEvent reinforced my respect for the backend work that keeps SaaS products running smoothly.

The value of shipping over perfecting In a small team building a large product, you learn quickly that perfect is the enemy of shipped. There were times I wanted another week to refine something, and times we shipped something knowing it would need iteration. The lesson wasn't to lower the bar, it was to recognize that getting something solid into users' hands is almost always better than polishing ad infinitum.

Architectural decisions compound I've been involved in many "v2.0" refactors in the past and this one was the most successful. I believe part of what made this experience work so well was the extensive planning we did at the beginning. Early architectural choices will ripple through a project for years. Asking "how will this feel at 10x the current scale?" before committing to an approach not because you should over-engineer, but because understanding the growth trajectory helps you make smarter tradeoffs in the moment.

There's something satisfying about building infrastructure that people rely on without thinking about it. Every time someone clicks "Add to Calendar" and an event lands on their calendar in the right timezone, on the right day, across the right platform, that's a chain of decisions and engineering work that has to go right every single time. I'm proud to have been part of the team that made that happen.