Back to blog

On Deck Case Study

Cover Image for On Deck Case Study
Egor Zaitsev
Egor Zaitsev

On Deck Case Study

Our first case study kicks off with Egor Zaitsev, Senior Software Engineer at On Deck. Welcome Egor and thank you for taking the time!

Let's dive straight in with the first question:

What does On Deck use Cal for?

Egor: On Deck is building a feedback marketplace, where Fellows can volunteer to provide pitch, product or other feedback to one another. After picking who you would like to get feedback from, Fellows are presented with a scheduling view from Cal to complete their booking.

What made you choose Cal to deliver your solution?

Egor: The existing solutions on the market either did not provide the necessary APIs or were not flexible enough for our use case. Cal gave us back days — if not weeks — that we would’ve otherwise spent developing everything from scratch.

How do you use Cal?

Egor: At the moment we are using a slightly modified self-hosted version of Cal for our solution. We automatically provision accounts for our Fellows and ask them to set up their availability and connect their Calendars. After they do it we begin showing them on our platform, embedding the scheduling UI.

What was the best thing about working with Cal as a platform?

Egor: Cal is extremely extensible and allows us to iterate fast.

Do you see potential future use-cases for Cal at On Deck?

Egor: We are already looking at using Cal for allowing our Fellows schedule meetings with each other as part of our other internal marketplaces as well as providing each Fellow with a personal scheduling service, hosted by On Deck.

How did Cal make it efficient for you to implement a solution like this?

Egor: Cal is built with extremely popular technologies and it was really easy to embed it into our ecosystem. In a couple of days time we had everything set up to provide our Fellows with the best scheduling experience possible!

Why were you not able to use other solutions in the market?

Egor: Calendly does not expose availability via its API, Motion does not have an API and building everything from scratch would’ve taken a lot of time.

If Cal didn’t exist, would you even have built what you built? How much longer would it have been?

Egor: Of course we would’ve been able to build what we did, albeit a lot slower and with more bugs at the start. Cal saved us days — if not weeks — of development.

What are you most excited about in the future of scheduling?

Egor: We’re really excited about scheduling going open source. Open source is the very power behind every successful startup and we are glad to be supporting yet another key part of a modern web becoming open source.

If you had one wish, what would you ask for?

Egor: Caching 😉 We’ve already implemented availability caching for ourselves, but I think it would be a very useful addition for those who use Cal at scale.


Thank you Egor!