Cal.com

Interview with Peer Richelsen: Co-Founder, Cal.com
By
Ben Rometsch
on
September 19, 2023
Ben Rometsch - Flagsmith
Ben Rometch
Host Interview
Host Interview

We required an open, extensible, and accessible scheduling product. That's something you can't do with SaaS

Peer Richelsen
Co-Founder
Peer Richelsen
Co-Founder
00:00
/
00:00
https://d2iwv8pn9yf3nf.cloudfront.net/LHfgiGy6z.mp3
00:00
/
00:00
https://d2iwv8pn9yf3nf.cloudfront.net/LHfgiGy6z.mp3

It takes great effort to build something with the fastest star growth count. And with Cal.com, they have the greatest domain, mission, and product that made that growth possible! In this episode, Peer Richelsen, the Co-Founder of Cal.com, takes us into the scheduling infrastructure they’ve built to help everyone focus on their meeting, not making meetings. Peer also touches on what he needs to qualify as an Open Scheduling. Meet Cal.com today and make booking easier for you.

---

I have Peer Richelsen with me who is in the Canary Islands. He is one of the founders of Calendso or Cal.com as you might know now. Peer, welcome.

Thank you for having me.

I didn't have time to get this data together, but I have a feeling that your project has the fastest star growth count on GitHub of anyone that I have spoken to so far. I guessed in my head how many you might have before we had this interview. You had double what I estimated. You are shot out the gate. Congratulations on that. It's great to see. Frustratingly for me, when I saw this project appear, I was like, “That's such an obvious thing to do an open-source project around.” I was kicking myself. I was like, “This is perfect.” For those of you who don't know, maybe you want to introduce the project a little bit and talk about that Genesis moment. I'd love to know about that because I was kicking myself.

It's still like a blurry dream. You wake up one day and suddenly you are running a company around something that you always had a side-project. To give you a bit of like a background. Back in 2021, I was running a different business called LeanHire.com, which is a hiring marketplace for freelancers to become full-time employees. As with any hiring business, Toptal, and geeks on Upwork, you need a good scheduling product because you are connecting contractors or employees with the companies.

There are a ton of amazing products out there like Calendly, SavvyCal, and Motion which give you a scheduling link. It makes it super easy to jump on a call for a podcast, a doctor’s appointment, or whatever. None of these SaaS products were built for marketplaces or anything that requires customizations and nitty-gritty infrastructure.

I see them more as consumer products, which is perfectly fine. For those either highly regulated or complex products, you need, in my opinion, an open infrastructure that you can use and make changes and truly own like you are in charge of the data and design and the workflow. My first gut reaction running that company was to go on Google and search for Calendly open-source, which is they are Supabase, a Firebase open-source, and Mattermost, which is Slack open-source.

It fairly become a trend now even after we have been going on. There's a ton of coverage about open-source for X. I didn't wake up one day and was like, “I want to start an open-source project.” It was more out of my requirement of running this marketplace that I had to find a scheduling service. If I found an open-source sketching solution, I wouldn't have had this interview.

To my surprise on Google, there weres no results. It was a ton of Reddit threats for people asking for an open-source which was like, “I'm one of them.” Even on Hacker News some people asking for it and no one seemed to find a solution. At that time, I was part of OnDeck, which is like a fellowship for entrepreneurs. You can post your ideas in the Slack channel and then people upload and comment on it. I was like, “Why has no one built the GitLab for Calendly?” What GitLab has done to GitHub is customizable self-hosting and very infrastructure-focused. GitHub is more consumer-focused and developer-focused.

People love the idea and I was like, “I think I got to get going.” An auto domain called Calendso is source open. I thought that was funny. I got Calend.so, which is also pretty neat as a short domain, and made pretty much a landing page with a prototype that you could use and pretty much outlining the value proposition that I was intending to build. It wasn't ready obviously, and I had a small Slack. We initially started with a Typeform and then Slack. The interest was crazy. Fast forward three months after the company, Lean Hire was acquired by OnDeck, the company that I was part of the fellowship because they were looking for a talent marketplace themselves.

I completely stopped working on Canlendso for six months. I had the landing page open, people were signing up and asking for changes. I was like, “I'm pretty sorry.” I remember I wrote an email to all of the people on the way saying, “The good news is my old company was acquired and I'm joining as head of product. The bad news is I don't know if I have time for this side project.”

Nothing was on GitHub at this point.

It was still private. It was intended to go live, but there was not anything you could use and I don't like having a GitHub project that doesn't go anywhere. I always recommend people switch it from private to public once they feel like it's usable. Otherwise, you attract the wrong type of people. You need some substance to get going essentially. That was not the case but your eyes, the mechanics, and ideas are like visual white paper written and the specs.

I went on Twitter to find someone who could take over the project. I was fully set up with the new job and the new project. I didn't find anyone. My last desperate move was to email everyone on the wait list because those are developers as well. I did 5, 6 or 7 interviews. The last person was my cofounder, who's Bailey. I hired him as a contractor and we'd put papers in a place where he would get massive ownership in the company. I would keep 10% and he would get 90%, but we were kicking it off early on and the project was growing fast when I then asked him like, “Can we do 50/50 and rejoin?”

I had a very amazing call with the leadership of OnDeck who also invested in the company and became one of the first customers for their fellowship program, which they are now actively using. We launched Product Hunt. That was a straight home run. I have never seen that. I have launched four projects on Product Hunt and none of them ever gained. They had 200 upvotes or something, which is great, but not exciting. That one pretty much did the entire launch because I wasn't involved in the project. I still saw it as if I was joining when it was required immediately because I was working at OnDeck for seven months and I was not looking to switch roles. I was stunned by the growth and the project.

The funny thing is we also posted it on Hacker News. I did YC back in 2019. They always say that you need to prepare your Hacker News launch, talk to the group partners, get the story right, and write paragraphs of your introduction and what the product does because the crowd is tough and you need to warm them up.

Get the story and write paragraphs of your introduction about what the product does because the crowd is tough, and you need to warm them up.

Bailey didn't know that. He posted the link. No text. Just links straight up with the title Open Source Calendly or something like that. Nothing else. Immediately we were Hacker News number one with millions of page views. It was on the same day we launched on Product Hunt and the GitHub repository went from 0 to 5,000 stars in several weeks. It's literally like a rocket graph, not even a hockey stick but up to the top.

Now as with every project, the growth has been slowing down a bit, but we are close to 10,000 stars in GitHub. It is a pretty overwhelming experience. We have a hosted plan which is Cal.com/your name. Over 13,000 users when we went live with the hosted product. There's a pro plan as well, which is to get more integrations and more event types.

Pretty soon after Product Hunt, as you may imagine, if you become a product of the day, week, or month, your inbox looks very interesting as a company. I have never experienced this because my previous companies were going sideways. It was not bad, but it was not exciting for VCs or for anyone to be chasing a deal. That was the first time I realized that there are two types of fundraising the ones where you take every check that you find and the other ones where you are trying to fit everyone in.

Being people of the best day.

That hasn't changed yet.

It's like product market fit. It's a bit like porn. You can't define it but you know it when you see it. I have started many side projects and businesses with other people in the past and you are like, “Is this it?” If you get involved with a company or a project, you are like, “I know this.”

I talked to the founder back in NYC and he was saying the same like, “You know product-market fit when you have it.” It’s pretty much the same phrasing. I was sitting in the car and was like, “That's the worst advice ever.” Now I'm like, “Pretty much, that's it.” I love that porn reference because also everyone involved gets messed up. It's crazy. Support tickets and couple up.

We have 170 open issues on GitHub and I don't know how we will ever go through them. I always joke, “Whatever product you have, at a certain size it breaks,” because there are people who run your software on a toaster or a Nokia flip phone and they'd be like, “I can't press this button.” You are like, “Why? It's not in the screen size.” At a certain size, everything breaks no matter how much you have prepared and that's what you experience when suddenly 13,000 people are making bookings. The company is very young. I don't remember if we incorporated it before or after Product Hunt, but it's not even a year yet.

Let's talk to me a little bit about the mindset or the thoughts that we are going through your head when you think about open-sourcing the project. Was the opportunity like, “There needs to be one. I'm going to be the person that builds it.” That's the experience that I had and the other guys that I was working with on Flagsmith.

To be fair, there was another project but it didn't look and feel like how we envisaged it. I have used open-source software all my life but I'm not religious about it. I'm using a Mac and earlier analytics on a desktop. My entire career has been working with it using libraries and whatnot. Was it the same with you? Was the open-source thing in your head like before you were searching GitHub or was it like the commercial open-source route is the opportunity?

It's great that you are saying that because I wrote a blog post about the decision-making process. The line of thinking for me and most, let's say, second-time founders is, “Do you want to find the best solution for the existing problem?” What you are referring to is some people are open-source diehards or not even diehards but they wake up and have this idea of, “I want to run an open-source company,” which is great because open-source is amazing, but that's not how you should think of starting an open-source company. I have learned tech with WordPress. The first half of my career was making changes to WordPress, selling websites, making plugins and themes, and nitty-gritty PHP stuff.

I have always been in love with the fact that I didn't even know that WordPress was a company up until 2 or 3 years in because I was like, “There's this group of people who give me free stuff. That's cool.” There's not a single developer who has never used any open-source technology, every programming language, pretty much open-source, compiler and framework.

For me, it felt natural to be doing and also giving something back eventually. That was not the reason why we started Calendso now called Cal.com because going back to the problem we required an open, extensible, and accessible scheduling product. That's something you can't do with SaaS. You can build like Stripe a very customizable SaaS product.

COS 52 | Scheduling Infrastructure
Scheduling Infrastructure: Cal.com requires an open, extensible, and accessible scheduling product, and that's just something you can't do with SaaS.

You are going to hit an offer and they are not going to start developing for you.

You will want to move the button or you want to change the color. What do you do, call Stripe customer support?” That’s my frustration with Calendly like, “This is great but give me the last 20% of my value.” It was pretty much from the get-go, the obvious choice to be open-source, not because I woke up one day and wanted to be open-source, but because it's the best tool for fixing the problem, which is open scheduling.

That's how I got into open-source. I did a lot of non-open-source. Pretty much all of the projects before I did were non-open-source. This feels amazing to see people and even their startups building on top of Cal like their own startups, the way I use React, which is an open-source, and Next.js. It's cool to see these layer effects where people start integrating it into their stack and building something completely new.

I’m curious to know if you are drowning under issues and stars. One of the things that I have found is there was a huge amount of people talking or blogging about who you go to for advice. It all manner of I think things that building the community and not going underwater in terms of issues and talking to people and the support on the commercial side. Did you feel like you were drowning at that point?

For the record, we have an amazing team that is now taking care of a lot of issues and customer support. Even in the early days, we have an open Slack channel that everyone can join. I love interacting with the community. We don't have two Slack channels. We have a single Slack channel, which is the entire organization, and then we have private channels for the team that is working alongside the community. Whenever someone has a problem we literally can open a new channel with the engineer plus a community member who has a problem, which is fantastic. The feedback cycle is fast to resolve issues and fix bugs. We are not drowning in that regard.

Is it right at the start?

It was interesting, especially initially when the product was very basic and there were a ton of things missing now. We feature parity with other products. It's hard to prioritize and balance what to ship first. Do you ship all kinds of integrations first like Google? We only had Google, Outlook, Apple, and Cal is a beast because that protocol is older than me and no one knows how to use it anymore. It's a lost knowledge. It's like ancient technology. Pretty much the entire world runs on Cal but no one knows it. Entire calendars run on Cal.

That was interesting to juggle. Luckily, I was running two companies before and one of them was very customer-intensive. It was a marketplace to buy and sell Magic cards. We had a north of 40,000 users. That were also a lot of high-frequency tickets and people having issues with the product they purchased because it's a two-sided marketplace.

The other person may screw up with the shipping or ship too late. There are a lot of moving pieces in a very operational business. I was prepared for the storm. We know that whatever happens, we will get it fixed. One thing I have learned is in one year no one will care. Even if there's something that seems like it's the worst thing, stuff is breaking and people get error messages straight off the launch, a year after the world looks entirely different. If you continue to do well, you have a good team and processes in place.

We have a ton of tests now. We didn't have any tests before. Whenever you make a new deployment, you have confidence that major things are still working. That's a good way of thinking like, “Is this a real big problem that Product Hunt us in one year?” Ninety-nine percent of those are not a problem in the year after.

Was having a paid service alongside an open-source product? In Flagsmith, in a way, it turns out that the enterprise market is way more important for us than the paid SaaS model. We didn't put much thought into that because it seemed like such a well-trodden path in terms of a multitude of other companies doing that.

I would expect a product like yours to be 80% of why you started it. Everyone's going to have the same 80% requirement but that last 20% is probably radically different from the customer. How have you threaded that needle of managing that? You eventually have to start saying no to a non-zero percentage of your customer base initially.

It's a very good point you are making about how you balance core products versus these niche features that people request. That's something we will launch and have a solution. We always launch every 30 days and on the 15th. The way we balance core features versus niche is we are launching “the app store for time” where anyone can build similar to WordPress extensions like niche plugins, which users can then activate or deactivate and integrate into their workflow. Let's make an example like crypto checkout, let's say, for bookings. That's probably not part of the core product because 99% have never heard of Web3. Maybe not 90% but half of our customers do not give a crap about crypto.

It shouldn't be in their core product. They can activate or deactivate it. That's a very good way to also involve the community. We may also launch some community fund where we help indie developers build extensions similar to WordPress has like developer programs to get going and build the ecosystem. I'm excited about that because it means that given the open nature of our product, anyone can interact with it and build themes, different categories or apps, and integrations to solve the last 10% for someone who runs a hairdresser or a yoga marketplace. That's how I see it going forward. For us as a company, it is exciting. We can work with many community members and help them maybe even build their businesses. If you take a look at the Slack app store, there are a ton of businesses and even unicorn businesses that only exist because of Slack.

Given the open nature of our product, anyone can interact with it.

It's the same for some of the Shopify. Those companies are enormous. Similar question but in terms of like open code, have you got closed components that are part of your SaaS platform or how did you think about that? That's something that we have struggled with, maybe not so much now, but in the early days, we struggled with a lot in terms of whether are we being too cautious or too open. It's very hard to get advice.

It's a very conflicting advice as well. There's a lot of conflicting advice around what you ship. In the community edition, we call it core then we have the enterprise edition which is single sign-on, paid video integrations, and Stripe checkout for example when you want to charge for a booking. Our line of thinking is every time it costs us money to run a service. We need to hand that cost over to the customer because otherwise, we would go out of business like the Stripes and SAML. We work with third parties and they cost money or the video integrations that we have, we pay for that. Those things require a commercial license, which a pretty straightforward. It's less than $0.5 and down to $0.1 depending on volume per booking.

If you run Cal on your infrastructure, you don't get that last 20% squeeze of customizability and data ownership. There are still some things where work with our partners and integrations. Whenever you make money, let's say with Stripe, PayPal, or crypto checkouts, then I think when you give a product out for free, which is the open core, that makes you money and drives your business, it's also fair in terms of compensation.

It's 0.5% plus $0.10 in transaction commission. That's working for us quite well and then we have a ton of enterprise customers who pay for SLA agreements, classic support, minimum support or minimum response time, and certain engineering hours for customizations. Those usually start at six figures because these are enterprise companies. They have deeper pockets than the classic startup. If you summarize our business, we have self-hosted free do whatever you want WordPress thing for indie developers or solo developers who want to have their website run on Cal.

We have the self-serve hosted plan, which is free or $12 per month. For everyone who already uses our scheduling products, first, you get a kick-ass domain Cal.com/something. I'm challenging every reader to find me a better domain for scheduling. I haven't found them yet. I was sunseting so that's sad. xAI is a pretty domain for scheduling too, but maybe X.com. Let me hit up. Maybe he's selling X.com.

Does he still own that? I don't know.

I think he owns it but I read a rumor that he's not allowed to sell it because I can somehow ban less than three words. There is some interesting weird stuff, but no one knows. It's still online. If you go to X.com, it shows an X. I don't know if that's ever been used in our lifetime, which is sad. I love that domain.

I remember in 1996, Cheese.com was a picture of a cartoon piece of cheese. That's what the internet was like in 1996.

I missed the first era of Web1. I was born into Web2, but I feel like everything is a joke initially and then it comes legitimate business. I remember my mom or my dad told me that when I first started surfing the web, “Never go to websites. Maybe there was even a campaign that was like Animal.com or Homework.com. Those are always scams because real businesses are called TheBestAnimalStore.com or something. “Never go to Animal.com. That's always a scam.” Now, if you get like Car.com, that's worth several million dollars. It's funny how pretty much reminds me of crypto and Web3 where it's like, “No, everything is a scam,” then 5 or 10 years down the road, not everything but the people who survived, are legitimate big things.

It was interesting what you are talking about domain because I hadn't considered it, but it is for a product like yours, it's core and a vital part of the experience.

There is this link-sharing business, Loom.com, where you send a video of your recording. I'm very certain that most of these businesses would not have the same commercial traction if they were called EasyVideoRecording.com or FastScheduling.bit.

It's weird. It's like you can't explain why that immediately turns you off, but it does.

Branding is a thing. You wouldn't drink like the neighbor's piss lemonade doesn't roll off the tongue that well.

The rapid rise of your open-source projects. How has that translated into the community? Almost everyone I have spoken to on this show has been the same story where at least 95% of the lines of code are committed by people being paid to write that code. Is that the same for you? Was that something that you were surprised at or trying to shepherd? How does it look and feel for you guys?

I would co-sign that argument that probably 90% to 95% is written. We have our team which is twelve people. 8 engineers and 4 non-technical non-engineers. Some founders are turned off by open-source because they are afraid that they lose control over the code base and their vision of what the product should look like. I have seen some free open-source software that looks like a patchwork because everyone is like, “There's no direction.” Everyone puts the button anywhere they want. It's like the Web1 open-source where there's no collective consent of what a good or bad product is. We are very strongly working with the core team but I always joke, “Lines of code don't mean quality,” and some of the best things have been built by the community who we ended up hiring later.

We work strongly with the core team, and the community built some of the best things.

Pretty much all of the core components that a community member built turned into a team member like the availability settings where you can set up like, “I'm available Monday but not on Tuesday.” That was built by a community member and we pretty much immediately hired them because we are like, “This is amazing. We need this. Are you available for the next few months?” They first started as a contractor and then slowly became a full-time employee.

Another example was the Stripe integration was completely built by someone who required Stripe themselves and was like, “I build it. May as well give it back.” We were like, “This is amazing. It's completely makes sense.” Same reaction like, “Do you want to do this more often?” The code ratio is quite high in terms of team, but then there are also critical bug fixes or smaller features that end up being super used and valued like the entire Docker repository for example, which takes care of all the different images and versioning and stuff is entirely built by the community.

We still give some guidance but that's something our core team doesn't have the capacity. Also, no one in our team has deep Docker expertise and there are some open-source contributors out there whose entire job is fixed Docker images and they love doing that. It's mental therapy for them too. Pop in and fix an image. It is definitely of high importance for us in terms of community.

What I imagine going back to the app store for time is that it may even get to 50/50 because software is never built, but the core product exists and then the vast majority of new features come through these niched apps that people build. If you think of the iOS app store, they were the first ones to launch the app store, but there were now millions, potentially billions. I haven't checked the numbers. How many apps are in the app store? I don't know. Hundreds of millions. That’s what I envision for us as well that we can build a good baseline and then people contribute and even get paid for it. My vision is that you can launch paid apps that cost something a month, one-time fees, or usage-based fees and we can do something similar at Shopify.

Were you quite influenced by WordPress in that regard? It's very close to their model.

It's close to pretty much everyone who's building an open-source platform. I see WebPress as the open infrastructure for information and we do it for time. There are a ton of similarities between the requirements of someone who uses WebPress over Webflow or some other. Webflow is very customizable because by design they made sure that it's customizable but still Webflow runs on a centralized server.

If they ever go down or get acquired by a random private equity firm and are shut down, you never know where companies go. With WordPress, if you run it on your self-hosted server, you know it's going to be there for the next 10 or 20 years unless you shut down the server. Adding that with the open ecosystem makes the most sense. In WordPress, I imagine had the same discussion internally of, “How do we deal with community contributions that are not part of the core?” Having that as a module that you can take out and re-add or something is the way forward for most open-source that want to have a strong core that's secure and stable while also offering the entire world of creativity to developers.

COS 52 | Scheduling Infrastructure
Scheduling Infrastructure: Webflow runs on a centralized server, and if it ever goes down or gets acquired and shut down by a random private equity firm, you never know where companies go.

What's the tooling like for that? Platforms written in JavaScript.

Node, TypeScript, React, and Next.js.

What's the notion of a plugin? Is there a lot of good tooling around that or is that stuff that you have to a lot of it you have to roll yourself to get to that state?

There's no real tooling around that, unfortunately. There are also some limitations. WordPress runs on PHP which has pretty good file support. You can unzip. That's something you don't do in Node unless I'm wrong. I don't think Node has the same but maybe now. For us, we initially will have all the apps in the repository. You make a pull request in the app folder and that app folder is being indexed and published, which also helps in terms of speed because you go to the app store and you activate an app and it's there.

You are lighting up some code.

In open core, there's a wrapper saying crypto app, whatever app or something app and then if it's activated, it becomes visible for the user. Going forward that's going to be the first plan. We do think of having a submodule where only the apps live maybe and that submodule is treated differently than the core repository. Maybe we even find a way to make it work that you can launch something outside of the app, put the zip, and unzip a zip folder in a certain directory and then it works.

I have seen for WordPress more problems than benefits with having the ability to put something in a folder. There are a lot of viruses that were sent that way. I feel very confident about having another layer of security for us to do PRs and have an app store admissions team that does security audits for each app because we also sell to enterprises and we don't want to have like an app somewhere that leaks certain information for sure or takes over someone's seller.

We sell to enterprises and don't want to have an app that leaks certain information, so we must add another layer of security.

You mentioned earlier about the fundraising. You raised some money with a star-studded set of investors. You know a number of the people that I have crossed paths with running Flagsmith as well. It seemed to be very much commercial open-source the way. We leave that and that's our thesis. We are going to bunch of money behind that thesis. Was that fundraising, was that more of a pull from you or a push from them?

I'd say, both. The team that we have raised from people like Naval who co-founded AngelList and is big in open-source, decentralization crypto, and Web3 are very much on the forefront of the web. He's been helpful with a ton of stuff, both product branding and high-level decisions. JJ who's GP and Cofounder of Open Source Capital is the lead investor. I'm pretty much texting him every two days about these things and he is responsive. I love working with him.

There are a ton of amazing other founders and operators. Leo Jiang who was part of Sequoia previously and Neha from Confluent and some other amazing open-source outcomes, MongoDB, and open-source capitals if the limited partners are mostly open-source veterans. I have been happy with the seed round. I would say it's both like a poll from the sheer amount of people reaching into our inbox and it's like you need to imagine you have thousands of people signing up and reporting box. It's just the two of you and at the same time, you have no money. You have your savings but you can't just hire three people and be like, “This is working,” because open-source is different than SaaS.

You end up not capturing a lot of value early on, which is great because you give stuff for free. You build a community and build commercial traction later on. We were like, “What do we do?” At the same time, you get all these amazing people to reach out and even a ton of VCs that we initially turned down because we were not looking for an early-priced round with a board member. It was a three-month project. No one knew what was going to happen. Even the fundraising was a bit more modular. We didn't set out to be like, “We want to raise $7 million.” It was like here and there, and having good conversations with all kinds of different people. It’s both a push for us to hire people and get this up and running, then also a pull from the market reaction.

In terms of the UX around self-hosting, is that something that you have spent a lot of time thinking about or are you thinking of one-click Deploy on DigitalOcean? We pushed a commit into CapRover, so you can start up Flagsmith if you have got a self a CapRover instance somewhere. Is that something that you guys have embraced or not?

We have a few buttons like Deploy and Heroku which had a few bucks. Those platforms change sometimes and versions are sometimes weird. Now and then, you need to fix some of the one-click deployment buttons and there's a one-click deployment for the railway, which is pretty cool. I don't remember if there was one for AWS.

Maybe not or maybe. To summarize, we don't focus on self-hosting yet. The deployment is quite trivial. It's a yarn build. It's a JavaScript repository that you would set up the same as you would set up your code. There's a PostgreSQL database which you can run on anything you want essentially. It's not that painful to get going for any engineer to whoever launched a PostgreSQL or a yarn app somewhere.

We work with Versal. Versal is amazing. They have a one-click deployment for the front end. In general, our goal is to drive the brand and pretty much the consumer-focused Cal.com usage because by doing that more people schedule calls, and then more people get aware of the brand and maybe they send it to a developer. The developer comes back to the repository to help us out and build it. Self-hosting is a great option for anyone to either save costs or have customizability.

Once you get the commercial license and access to a ton of new features that the open core doesn't have. It's not the main priority. The main priority of have a very stable core product and core hosted in general but always be open to it. If anyone wants to have a one-click button for DigitalOcean, which we don't have, we are always happy to merge that and write some documentation around it.

Self-hosting is a great option for anyone to save costs or have customizability. Once you commercialize, get the commercial license and get access to new features that the open core doesn't have.

I have to ask you this. What's the maddest calendaring crazy situational bug or issue in a library that you found?

I did not expect that. We are at a point where we need to pay this engineer who's working on time zones like some damages. You age faster by thinking about time.

It looks like danger money for seed divers or something.

I have learned that there's a time zone which is fifteen minutes. I didn't know that. If you take a look at the Gregorian calendar, every 100 years or something, another thing changes. Another day is being removed somewhere. Not only every four years but also every 100 years. One thing that surprised us was when daylight savings switched.

Time goes backwards.

When people made a booking in the future, but the future was already daylight savings before and then you made the booking, hundreds, maybe even thousands of people had a booking at the wrong time. We had to change to complete a different time format to save that. Once daylight saving was over then that would not happen.

COS 52 | Scheduling Infrastructure
Scheduling Infrastructure: With daylight savings, many people could book at the wrong time when booking in the future. So, Cal.com had to change a different time format to save that.

For this short amount of time when people were still pre-daylight savings and then made bookings after daylight savings, it hit the fan. You think about daylight savings and you implement it correctly. We use libraries and tons of this calendar and time. Luckily, they figured that stuff out. You'd think you did, but it only takes one daylight savings event to realize, “We did not prepare for this.”

I'm working with a couple of guys in California. There's one week where in the time zone the clock changes in the UK. One week was wrong. We moved and then a week later, they moved. For that week, we try not to, “Let's not have meetings that week because no one knows what is going on.” There's another guy that I'm working with in India and they are five and a half, then Russia changed. They moved a bunch of their time. That was probably a few years ago. I remember a long time ago, I wrote some code that didn't consider time going backward. It's probably worse when you have thousands of customers I guess.

That's also the beauty of our company we haven't even talked about. We have 9 or 10 different nationalities not in every time zone but we have people from close to China up to Brazil and then we don't have anyone in New Zealand. That's the beauty of the new remote work where you now see the problems. If we were like, let's say, a gang of White men in San Francisco building something for the entire world that you wouldn't know about the things you said. It's cool to have this diverse team and people who have daylight savings in different countries' experiences and can at least figure out how things work in their local regions. We worked with someone who moved from China to Canada and they told me, “Call me naïve. Maybe that's something you don't know, but there's a different calendar.”

There are tons of calendars, including the Gregorian calendar, and the previous ones but there are still people who use the Chinese calendar which takes months. I need to research. I should know that then I had an internal discussion with a team of like, “Do we support this? This is already breaking. Do we now launch a different calendar?” All these things pretty much go back to why we need Cal. If you run a hiring marketplace, you don't want to be dealing with that. You want to be focusing on finding people's jobs. If you run a marketplace to give out yoga lessons, you don't want to be dealing with time zones. I love having out-of-the-box technology such as Stripe.

COS 52 | Scheduling Infrastructure
Scheduling Infrastructure: If you run a hiring marketplace, you don't want to deal with that. Focus on finding people's jobs.

We use Stripe. I love Stripe. That handles all of the currency conversions, payment fees, providers, and credit cards. You want to focus on your business, not on the infrastructure. Something we get a lot from our customers is, “Once we fixed all of these things, there's no reason to reinvent the wheel. You are going to end up using our infrastructure, which is great,” because that way we can build a massive company and go public. I'm joking. The time zone is a pain and then the calendar is another pain. Calendar protocols were built in the ‘90s.

They all are like SMTP where it's unstructured text and anything goes.

There's CalDAV which is supposed to be a protocol standard, but every CalDAV provider made some changes or some add-ons that don't work. Basic stuff like recurring events. If are you making a Google calendar, you make a recurring event. That works brilliantly. If you now want to build a recurring product for us, you could use the Google protocol to have the recurring event but that may not work for, the CalDAV of the next cloud or something. It's a very interesting minefield to be finding all the differences and building bridges to resolve them.

COS 52 | Scheduling Infrastructure
Scheduling Infrastructure: If you now want to build a recurring product for us, you could use the Google protocol to have the recurring event.

Danger money is required there. It's not the thing that most people know.

At the end of the day, it's fun because most engineers want to have those problems. Even though they may go on Twitter and be like, “I hate time zones,” they still like working on hard problems. No one wants to push some pixels. It's satisfying once you fix these time zone conflicts.

It's been great talking to you. It has been surreal talking to these different founders seeing them on these trajectories and then putting a face to the hub repository. Thank you so much. I look forward to seeing what comes next. I have got great expectations.

Thank you so much for having me. It was a pleasure to be talking about open-source.

Take care.

Important Links

About
Peer Richelsen

Co-Founder at Cal.com. I auto-accept everyone who adds me. Not active on LinkedIn. Please email me or DM me on twitter.com/Peer_Rich

Available for talk, coaching and workshops on:

Subscribe

Learn more about CI/CD, AB Testing and all that great stuff

Success!
We'll keep you up to date with the latest Flagsmith news.
Must be a valid email
Illustration Letter